Hello,
I tried using Force https and it seemed to work for me except it was causing login problems. However, the logos are loaded using http by default. They should use the // protocol and let the browser decide which one to use, right? Or maybe there is another solution I’m missing?
Thanks
Hi Eddie,
What version of Discourse are you running? In recent versions logos are uploaded via site settings, instead of being linked using a URL, so this should no longer be an issue.
Hi Joshua, We recently upgraded to v2.2.5. During the previous upgrade, before force https, I believe I deleted the post where the logos were uploaded and switched to the site settings. Everything was fine. Then with v2.2.5, I can’t get rid of the http:// part without force https. I tried reuploading, the wizard, even modifying the images so their hash was different. No luck
Sorry, now I’m confused. Is force_https enabled or not? Is there any possibility you’re overriding the uploaded logos via themes? If your force_https is enabled, and your logos are served via site settings, there should not be a mixed content warning. Are you able to share a link to your site so I can take a look?
It was enabled, thought the upgrade was over. Then our QA reports that logins are not working. so we disabled force https for now. You can test here //forum.y8.com
I checked the themes and didn’t spot anything that might cause this https problem. We mostly use stock, though it is an old stock theme.
With force_https disabled, I can’t test this. We rely on that setting to ensure assets are served over https, not http. Regarding the login issue, it appears you’re using SSO, so ensure the SSO redirect from your provider links to your site via https://, not http://. Once you’ve re-enabled force_https I can take another look.
This forum is using the oauth2 basic plugin. Maybe there is a problem with that, might require a version roll back. Not sure yet. I did check the settings, all addresses were using https, so no obvious problem there.
У меня здесь похожая проблема:
После того как выяснилось, что логотип и большая иконка загружаются по HTTP, что вызывает смешанный контент, включение force_https исправило это. Однако вход стал невозможен, что привело к циклу перенаправлений. После отключения этой опции вход снова работает.
Почему это происходит?
И почему только эти два изображения загружаются по HTTP, тогда как все остальные ресурсы корректно загружаются по HTTPS?
Какой у вас метод входа? Я предполагаю, что это не локальный вход (имя пользователя/пароль)?
Есть ли перед вашей установкой прокси-сервер или другая служба?
Я использую SSO через другое веб-приложение.
В качестве обратного прокси используется nginx.
Как был настроен nginx?
Nginx перенаправляет все HTTP-запросы на HTTPS, поэтому загрузка контента через HTTP в любом случае невозможна.
Моя первая мысль — дважды проверить вашу конфигурацию SSO, чтобы увидеть, куда она перенаправляет пользователей, а также какие исходные домены она принимает. Убедитесь, что в конфигурации SSO везде используется https://. Также возможно, что проблема связана с Nginx. Отладить это будет непросто из-за множества переменных…
У меня точно такая же проблема, как у людей, сообщивших об этом здесь и в этой теме.
Проблема не связана ни с реализацией SSO, ни с веб-сервером: в моём случае HTTP-запросы перенаправляются на HTTPS, после чего проходят через обратный прокси. SSO работает идеально, если я перенаправляю пользователя на https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE, а параметр force_https установлен в false. Это подтверждает, что как часть SSO, так и прокси работают безупречно. Проблема возникает только тогда, когда я переключаю force_https на true — всё перестаёт работать. Если у меня уже есть активная сессия, я могу изменить force_https на true и использовать Discourse без каких-либо проблем, что ещё раз подтверждает: проблема не связана с обратным прокси. Оставлять force_https равным false нельзя, так как это ломает отображение логотипов, а Chrome недоволен смешиванием ресурсов с HTTP и HTTPS (он показывает небольшое предупреждение в адресной строке о том, что страница небезопасна).
Как выглядит ваш конфиг nginx и есть ли в нём заголовок X-Forwarded-Proto?
Спасибо большое. Да, это решило проблему. Так что дело действительно было в прокси. Извините, что я изначально предположил обратное, просто потому что контент загружался.
Для полноты картины: я использую Apache в качестве обратного прокси, а не nginx. Вот соответствующие строки конфигурации:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
Добавление первой строки решило проблему.
Привет,
извините, что снова поднимаю эту тему. Дело в том, что я не могу избавиться от предупреждений о смешанном контенте в Firefox. Странно, что у меня практически такая же настройка… во всяком случае, примерно такая. Возможно, кто-то сможет предложить идеи или улучшения. Я не очень большой эксперт в директивах Apache, но для меня это имеет смысл – хотя бы отчасти.
У нас Discourse работает в Docker за Apache через обратный прокси, а сертификаты Let’s Encrypt управляются через ISPConfig, так как на нашем сервере работает много «обычных» доменов.
Мы настроили обратный прокси с помощью директив Apache в ISPConfig. Наша настройка выглядит так:
ProxyPreserveHost On
ProxyPass /.well-known/acme-challenge !
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:///var/discourse/shared/standalone/nginx.http.sock|http://localhost/
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://sub.domain.de$1 [R,L]
Но в Firefox всё ещё появляются предупреждения о смешанном контенте. Я пробовал включить опцию «Принудительный SSL» в настройках. В результате сначала мы вообще не могли войти в систему. У нас используется только аутентификация по имени пользователя и паролю. Тогда я попробовал решение, упомянутое здесь:
Теперь «Принудительный SSL» работает, и вход возможен. Но Firefox всё ещё показывает предупреждения о смешанном контенте. В консоли указано:
и
эти изображения загружаются по HTTP… Мы также пробовали повторно загрузить эти изображения брендинга через sub.domain.de/wizard, но проблема всё ещё сохраняется… Есть ли способ… не знаю, заставить переотрендерить оптимизированные изображения через HTTPS? Неужели что-то не так с нашей настройкой обратного прокси?
Буду очень благодарен за любую дальнейшую помощь. Это как океан возможных конфигураций обратного прокси с принудительным SSL через Let’s Encrypt (обрабатываемый) Apache (а не встроенный в конфигурацию Discourse), и я чувствую, что тону. Мне кажется, что очень мало людей используют Apache в качестве хоста с обратным прокси и такой настройкой Let’s Encrypt. Или же мы просто настраиваем это неправильно.
Как я уже сказал, буду признателен за любые подсказки. Заранее спасибо!
Попробуйте выполнить SiteIconManager.ensure_optimized! из консоли Rails.
Вау, такой быстрый ответ! Большое спасибо.
Тем временем… Не знаю, сработало ли это из-за того, что прошло какое-то время и что-то произошло. Но после отправки моего первого поста я просто снова загрузил эти изображения (favicon и apple icon), не используя мастер, а через настройки администратора (брендинг). И именно в тот момент, когда я хотел закрыть вкладку, чтобы перепроверить, работает ли вход и всё ли теперь корректно… Угадайте что? Ошибки смешанного контента в Firefox исчезли!
Вау!
Что ж, @RGJ, ещё раз огромное спасибо. Думаю, это также исправит перерисовку оптимизированных изображений. Как вы думаете, это сработало из-за временного порога или из-за повторной загрузки изображений через панель администратора, а не через мастер?
Ещё раз спасибо, особенно @alphanoob1337, за то, что наконец-то всё заработало!
Вау, это довольно неудобно для понедельника, но я ухожу с рабочего места с приятным, счастливым ощущением 
