Topic: Проблема с https при использовании apache + nginx

[Webpatron]

В общем вот такая беда:

Имеем сайт, который работает только по https.
На сервере apache, а перед ним nginx.

В такой связке заставить нормально Mibew Messenger не удалось, хоть он стоит также на https
Проблемы на сайте:
1. Не открывается окно чата. Работает только в новом окне.
2. Приглашения всплывают, но окно приглашения пустое, то есть текста в нём нет.

В настройках Mibew стоит "Разрешать защищенные соединения (SSL)". Вторая галочка: "Принудительно переводить все чаты в защищенный режим" не отмечена, так как из-за nginx в этом случае будет циклическая переадресация.

Теперь смотрите, выше описанные проблемы получаются из за того, что запросы Mibew отправляет всё равно по http и грузить пытается http.

То есть к примеру окно приглашения не правильно работает из-за ошибки в widget.js:18:

Code: [Select]

Mixed Content: The page at 'https://domain.net/' was loaded over HTTPS, but requested an insecure resource 'http://support.domain.net/chat/invitation'. This request has been blocked; the content must be served over HTTPS.

Где domain.net это сайт, support.domain.net - это адрес, где стоит Mibew. Причём support.domain.net работает тоже только по https, то есть настроена принудительная переадресация через nginx.

Вопрос: возможно ли как то заставить Mibew понимать, что если он выводится на сайте с кодом для https и в его настройках стоит разрешение на использование https, то и грузить всё по https.

Ведь без использования nginx при включении принудительного перевода на https всё работает.

[faf]

Хм. Пока что не вдаваясь в особенности правильной настройки связки nginx и Apache при использовании HTTPS, пример которой виден на наших демо-установках, задам глупый вопрос:

А галочку "Использовать защищенное соединение (https)" при генерации кнопки Вы отметили?

[Webpatron]

А галочку "Использовать защищенное соединение (https)" при генерации кнопки Вы отметили?

Да, конечно, иначе бы вообще бы ничего не работало.

По поводу настройки nginx - здесь дело в том, что такой конфиг генерируется панелью управления ISPmanager, да и я если честно, не совсем понимаю, как можно по другому.

apache там висит на 81 порту, nginx на 80 и 443. Если делаем редирект на https средствами apache, то получаем:
запрос приходит на 80 порт,
проксируется на 81,
редиректится на 443,
снова проксируется на 81,
и так по кругу, то есть получается циклическая переадресация.

То есть принудительный редирект в данном случае настраивается именно в nginx, то есть пришёл запрос на 80 порт, его средиректило на 443 и затем проксируется на 80.

Но вопрос то по сути не в этом, вопрос в том, что именно делает галочка "принудительного перевода в https"?
Ведь не только же она редирект вызывает? Что-то она ещё переключает. В случае с apache ведь всё работает. В чат всё тянется именно по https.

А если она не стоит, то кое что пытается через http пробиться. По сути, раз стоит галочка "разрешить https", и код получен для https то уже нужно по https всё грузить.

Вот сделал живой пример: https://test.webpatron.net/1.html

При нажатии на кнопку файл /styles/chats/default/iframe.css зачем то по http хочет загрузится, но естественно не может и соответственно окна чата просто нет.

Здесь даже смотрите, что получается:

Заставить нормально работать чат на https можно только включив галочку "Принудительно переводить все чаты в защищенный режим".

Но в этом случае, зачем же тогда галочка "Разрешать защищенные соединения (SSL)"? Ведь в ней выходит смысла нет.

Я так понимаю, что она была задумана, чтобы можно было к примеру чат выводить на разных сайтах - на одних по http, на других по https.

Сейчас же такое не получится, на сайтах с https в данном случае чат работать не будет

[faf]

Для решения проблемы прежде всего требуется её понимание и формализация.

Если я правильно понимаю, то nginx у Вас - проксирующий веб-сервер, который принимает запросы и по HTTP, и по HTTPS, осуществляя при этом редирект всего HTTP-трафика на HTTPS, а трафик по HTTPS прокидывая на порт Apache.

Apache при этом работает по протоколу HTTP и знать не знает ни про nginx, ни про то, что первоначально обращения клиентов идут по HTTPS. И не должен знать.

Mibew Messenger - это серверное PHP-приложение, работающее под управлением Apache. И знает оно ещё меньше, чем Apache. Оно работает с некими входящими запросами. Запросы эти приходят по протоколу HTTP. Про наличие nginx, превращающего HTTPS в HTTP Mibew не знает.

Настройки Mibew Messenger, связанные с HTTPS, реально связаны с работой по протоколу HTTPS. Т.е. они расчитаны на ситуацию, когда никакого nginx перед Apache нет, и Apache сам обрабатывает HTTPS-запросы. Вот для этого случая и нужны настройки типа принудительного перевода в защищённый режим и т.п. Как следствие, их трогать не нужно. Потому что у Вас Mibew, фактически, работает по HTTP.

Т.е. в плане настроек Mibew необходимо и достаточно просто сгенерировать кнопку с именем хоста и https-ссылками. Более ничего делать не нужно.

Где возникает проблема? Проблема возникает там, где требуется динамическая генерация полного URL (например, для стилей приглашения). Потому что в этой ситуации Mibew нужно как-то узнать, что схема для полного URL должна быть https://.

Является ли багом отсутствие соответствующей сохранённой информации в настройках виджета в случае генерации кнопки с использованием https-ссылок - это вопрос, который мы ещё будем изучать в рамках проекта. Возможно, что действительно баг. Тогда исправим к следующему обновлению.

Но в общем случае правильным решением подобной проблемы является установка корректных переменных окружения для PHP-приложения. Например, на уровне конфигурации Apache с помощью модуля env_module:

Code: [Select]

        <IfModule env_module>
            SetEnv HTTP_PORT 443
            SetEnv HTTP_SCHEME https
            SetEnv HTTPS on
            SetEnv HTTP_HOSTNAME secure.example.com
        </IfModule>

Ну или просто где-то в начале, не знаю, index.php, например, пропишите:

Code: [Select]

$_SERVER['HTTPS'] = 'on';
Но этот вариант хуже, т.к. тогда при обновлении Mibew придётся каждый раз вносить это изменение.

[Webpatron]

Ага, спасибо большое!

Так действительно работает. 

Но вообще, я всё же склоняюсь, что эту проблему нужно как то попытаться решить на уровне приложения.

Ибо, как я уже писал выше, сейчас получается абсолютно бесполезной галочка "Разрешать защищенные соединения (SSL)" и генерация кода для https, так как на https сайте чат без указания принудительного https чат работать не будет.

Спасибо ещё раз и удачи в развитии проекта!

PS: А API уже полноценно реализовано? И есть ли хоть какая-то документация?

[faf]

Но вообще, я всё же склоняюсь, что эту проблему нужно как то попытаться решить на уровне приложения.

1. Pull-request'ы приветствуются.
2. Можете тогда и разработчикам, например, Wordpress это посоветовать. Там ситуация аналогична. 

Ибо, как я уже писал выше, сейчас получается абсолютно бесполезной галочка "Разрешать защищенные соединения (SSL)" и генерация кода для https, так как на https сайте чат без указания принудительного https чат работать не будет.

В Вашем случае - возможно. В случае, когда, например, Apache напрямую работает и по HTTP, и по HTTPS, а кнопка использует относительные пути - нет.

PS: А API уже полноценно реализовано? И есть ли хоть какая-то документация?

В целом, API финализирован. Но в рамках одного топика обсуждается один вопрос: форум - это не частная переписка. Зададите отдельный вопрос - напишу, где и на что смотреть.