Сработает ли простое proxy_set_header X-Forwarded-Proto https;?
Запрос http/s отправляется из контейнера на сервер IDP для Discourse ID в интернете. Между ними нет экземпляра, где можно было бы добавить или изменить заголовки запроса.
На мой взгляд, и предполагая, что «Discourse ID» — это стандартный OAuth, правильным решением было бы либо:
a) наличие опции конфигурации для Discourse ID, где можно было бы указать «well-known» конечную точку конфигурации, содержащую все необходимые значения конфигурации OIDC, включая префикс «https://…».
b) то же самое, но уже зашитое в код.
Я всё ещё разбираюсь в технических деталях Discourse ID…
Вы можете найти детали идентификатора Discourse в нашем коде: протокол, который мы используем, полностью описан в нашем репозитории на GitHub. Единственное отличие от других реализаций OAuth — мы автоматически регистрируем экземпляр. В процессе этой автоматической регистрации мы проверяем, что запрашивающий регистрацию экземпляр действительно является тем, за кого себя выдает, и использует https (в наши дни ни один экземпляр Discourse не должен работать по http://).
Ошибки http, которые я привёл выше, указывают на то, что ваш сайт настроен неправильно.
Пожалуйста, проверьте вывод следующих команд в консоли:
Discourse.base_url
SiteSetting.force_https
Если первая команда возвращает URL, начинающийся с http://, а вторая — false, возможно, стоит установить SiteSetting.force_https = true и проверить, решит ли это проблему. (Однако, если конфигурация в других местах неверна, это может привести к сбоям. Будьте осторожны.)
Привет, Пенар,
возможно, нам сначала стоит уточнить детали моей конфигурации. Она немного отличается от стандартного развёртывания.
- Центральный балансировщик нагрузки (https://www.haproxy.org/), выступающий в роли SSL-акселератора для нескольких веб-сервисов (не только Discourse). Доступ из Интернета к любым из этих сервисов разрешён только через HTTPS. Переход с HTTP на HTTPS осуществляется непосредственно на балансировщике нагрузки, см. Redirect HTTP to HTTPS in a Few Easy Steps with HAProxy для справки.
- HAProxy пересылает фронтенд-запросы на бэкенд в частной сети (10.x.x.x) без шифрования. Этот трафик завершается на локальном nginx на хосте Docker.
- Nginx пересылает запросы на HTTP-сокет контейнера web_only с помощью
proxy_pass ``http://unix``:/mnt/data/discourse/shared/web-only/nginx.http.sock
(Я использую двухконтейнерную конфигурацию с файлами web_only.yml и data.yml). См. templates/web.socketed.template.yml для справки.
Мне не требуется SiteSetting.force_https, так как всё шифрование HTTPS выполняется вне контейнера Discourse. Я уже использую OAuth на основе плагина Discourse OpenID Connect (OIDC) и свой собственный IDP. В плагине Discourse OIDC есть настройка для «well-known» документа обнаружения OpenID Connect. В моём случае это: https://login.netzwissen.de/realms/netzwissen/.well-known/openid-configuration.
Если бы функция Discourse ID реализовывала нечто подобное для связи между экземпляром контейнера Discourse и IDP Discourse ID, проблем бы не возникло. Поскольку «Discourse ID» использует фиксированный IDP, такой «well-known URL» можно даже зашить в код, включая префикс https.
Томас, извини, я не могу помочь тебе с твоим конкретным настроением. Всё, что я могу сказать, это то, что в твоем экземпляре что-то неверно.
Так вот, консоль JavaScript на твоем сайте не считает, что шифрование HTTPS вне контейнера покрывает всё. Предупреждения JS, которые я привёл выше, являются симптомами аналогичной проблемы, с которой ты сталкиваешься: сам Discourse в твоей настройке считает, что работает в http, и это проблема, потому что в некоторых случаях он будет генерировать URL-адреса в http.
Извините, очень-очень-очень извините:
Я сравнил настройки на нашей рабочей инстансе (PROD) с настройками на DEV-инстансе. Только на DEV-инстансе было отключено параметр force_https. И это работало только потому, что перед ним у нас стоит SSL-ускоритель HAProxy.
Теперь я активировал SiteSetting.force_https на DEV-инстансе, и Discourse ID работает нормально. Поэтому я также разверну Discourse ID на нашей рабочей инстансе (forum.netzwissen.de).
Извините за путаницу.
Не переживайте, рад, что всё уладилось. Спасибо за уточнение!