强制 HTTPS 和混合 HTTPS 内容的问题

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.

由于 force_https 已禁用,我无法测试此问题。我们依赖该设置确保资源通过 https 而非 http 提供。关于登录问题,您似乎正在使用 SSO,请确保 SSO 提供商的重定向链接通过 https:// 而非 http:// 指向您的站点。在您重新启用 force_https 后,我可以再次查看。

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.

我在这里遇到了类似的问题:
在发现logolarge icon通过 HTTP 加载导致混合内容问题后,启用force_https解决了该问题。但登录功能无法使用,导致出现重定向循环。禁用该选项后,登录功能恢复正常。
为什么会发生这种情况?
为什么只有这两张图片通过 HTTP 加载,而其他所有资源都能正确通过 HTTPS 加载?

您的登录方式是什么?我猜不是本地(用户名/密码)登录吧?

您的安装前方是否有代理或其他服务?

我通过另一个 Web 应用程序使用 SSO。
nginx 用作反向代理。

nginx 是如何配置的?

Nginx 正在将所有 HTTP 请求重定向到 HTTPS,因此无论如何都无法通过 HTTP 加载内容。

我的第一反应是双重检查您的 SSO 配置,查看它正在将用户重定向到哪里,以及它接受哪些来源。请确保 SSO 配置中的所有内容都使用 https://。这也可能是 Nginx 的问题。由于存在多个变量,在此处进行调试会非常困难…

我和这里报告问题的人以及这个 讨论帖 中的人遇到了完全相同的问题。

问题与 SSO 实现或 Web 服务器无关:在我的情况下,HTTP 请求会被重定向到 HTTPS,然后通过反向代理发送。如果我将用户重定向到 https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE 并将 force_https 设置为 false,SSO 可以完美运行。这表明 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 指令方面的专家,但这对我来说至少有点道理。

我们在 Docker 中运行 Discourse,通过 Apache 的反向代理访问,并使用 ISPConfig 处理 Let’s Encrypt 证书,因为我们的服务器上运行着许多“普通”域名。

我们通过 ISPConfig 中的 Apache 指令配置了反向代理。我们的设置如下:

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://forum.suro2030.de/uploads/default/optimized/2X/6/67817e7f1257a3f393ecc85c43dd9bdcce217fca_2_180x180.png

以及

http://forum.suro2030.de/uploads/default/optimized/2X/4/4f5d4076a6a0e6641183b611d49a72f639ca69f8_2_32x32.png

这些资源是通过 HTTP 提供的……我们还尝试通过 sub.domain.de/wizard 重新上传这些品牌图片,但仍然遇到同样的问题……有没有办法……我不知道是否强制使用 HTTPS 重新渲染优化后的图片?我们的反向代理配置是否有问题?

我非常感激进一步的帮助。这就像是一片由 Let’s Encrypt(通过 Apache 处理,而非 Discourse 内置配置)强制启用 SSL 的反向代理配置的汪洋大海,我觉得自己快要淹死了。而且我感觉,使用 Apache 作为主机并通过反向代理配合我们这种 Let’s Encrypt 配置的人并不多。或者只是我们配置错了。

如我所说,我非常感谢任何提示。提前感谢!

尝试在 Rails 控制台中运行 SiteIconManager.ensure_optimized!

哇,回答得这么快!非常感谢。

不过在此期间……我不确定这是否是因为让时间流逝,导致某件事发生了。但在我发布第一个帖子后,我重新上传了那些图片(favicon 和 Apple 图标),这次没有使用向导,而是通过管理设置(品牌)完成的。就在那一刻,我想关闭标签页,顺便检查一下登录等功能是否现在都正常工作了……你猜怎么着?Firefox 的混合内容错误消失了!

太棒了!

那么,@RGJ,再次非常感谢。我想这应该也能解决优化图片的重新渲染问题。你觉得这是因为达到了某个时间阈值而触发的,还是因为通过管理面板(而非向导)重新上传了图片而触发的?

再次感谢,尤其是 @alphanoob1337,终于让这一切正常运行了!
哇,这在周一离开办公室时能让人带着愉快的心情,真是挺不错的 :wink: