General > Русский (ru)
Проблема с https при использовании apache + nginx
Webpatron:
В общем вот такая беда:
Имеем сайт, который работает только по https.
На сервере apache, а перед ним nginx.
В такой связке заставить нормально Mibew Messenger не удалось, хоть он стоит также на https
Проблемы на сайте:
1. Не открывается окно чата. Работает только в новом окне.
2. Приглашения всплывают, но окно приглашения пустое, то есть текста в нём нет.
В настройках Mibew стоит "Разрешать защищенные соединения (SSL)". Вторая галочка: "Принудительно переводить все чаты в защищенный режим" не отмечена, так как из-за nginx в этом случае будет циклическая переадресация.
Теперь смотрите, выше описанные проблемы получаются из за того, что запросы Mibew отправляет всё равно по http и грузить пытается http.
То есть к примеру окно приглашения не правильно работает из-за ошибки в widget.js:18:
--- Code: ---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.
--- End code ---
Где domain.net это сайт, support.domain.net - это адрес, где стоит Mibew. Причём support.domain.net работает тоже только по https, то есть настроена принудительная переадресация через nginx.
Вопрос: возможно ли как то заставить Mibew понимать, что если он выводится на сайте с кодом для https и в его настройках стоит разрешение на использование https, то и грузить всё по https.
Ведь без использования nginx при включении принудительного перевода на https всё работает. :)
faf:
Хм. Пока что не вдаваясь в особенности правильной настройки связки nginx и Apache при использовании HTTPS, пример которой виден на наших демо-установках, задам глупый вопрос:
А галочку "Использовать защищенное соединение (https)" при генерации кнопки Вы отметили?
Webpatron:
--- Quote from: faf on March 10, 2015, 09:05:52 AM ---А галочку "Использовать защищенное соединение (https)" при генерации кнопки Вы отметили?
--- End quote ---
Да, конечно, иначе бы вообще бы ничего не работало.
По поводу настройки 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: --- <IfModule env_module>
SetEnv HTTP_PORT 443
SetEnv HTTP_SCHEME https
SetEnv HTTPS on
SetEnv HTTP_HOSTNAME secure.example.com
</IfModule>
--- End code ---
Ну или просто где-то в начале, не знаю, index.php, например, пропишите:
--- Code: ---$_SERVER['HTTPS'] = 'on';
--- End code ---
Но этот вариант хуже, т.к. тогда при обновлении Mibew придётся каждый раз вносить это изменение.
Webpatron:
Ага, спасибо большое!
Так действительно работает. :)
Но вообще, я всё же склоняюсь, что эту проблему нужно как то попытаться решить на уровне приложения.
Ибо, как я уже писал выше, сейчас получается абсолютно бесполезной галочка "Разрешать защищенные соединения (SSL)" и генерация кода для https, так как на https сайте чат без указания принудительного https чат работать не будет.
Спасибо ещё раз и удачи в развитии проекта!
PS: А API уже полноценно реализовано? И есть ли хоть какая-то документация?
Navigation
[0] Message Index
[#] Next page
Go to full version