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.
Ich habe hier ein ähnliches Problem:
Nachdem festgestellt wurde, dass das Logo und das große Symbol über HTTP geladen werden, was zu gemischten Inhalten führt, hat die Aktivierung von force_https dies behoben. Eine Anmeldung war jedoch nicht mehr möglich, was zu einer Redirect-Schleife führte. Nach dem Deaktivieren dieser Option funktioniert die Anmeldung wieder.
Warum passiert das?
Und warum werden nur diese beiden Bilder über HTTP geladen, während alle anderen Assets korrekt über HTTPS geladen werden?
Welche Anmelde-Methode verwenden Sie? Ich vermute, es ist keine lokale Anmeldung (Benutzername/Passwort)?
Gibt es einen Proxy oder einen anderen Dienst vor Ihrer Installation?
Ich verwende SSO über eine andere Webanwendung.
nginx wird als Reverse-Proxy verwendet.
Wie wurde nginx konfiguriert?
Nginx leitet alle HTTP-Anfragen an HTTPS um, sodass es ohnehin nicht möglich sein sollte, Inhalte über HTTP zu laden.
Mein erster Gedanke wäre, Ihre SSO-Konfiguration zu überprüfen, um zu sehen, wohin sie Benutzer weiterleitet und welche Ursprünge sie akzeptiert. Stellen Sie sicher, dass alles in der SSO-Konfiguration https:// verwendet. Es ist auch möglich, dass dies ein Nginx-Problem ist. Mit mehreren Variablen wird es hier schwer zu debuggen sein…
Ich habe exakt das gleiche Problem wie die Personen, die hier und in diesem Thread berichten.
Das Problem liegt nicht an der SSO-Implementierung oder dem Webserver: In meinem Fall werden HTTP-Anfragen zu HTTPS umgeleitet, was dann über den Reverse-Proxy gesendet wird. SSO funktioniert einwandfrei, wenn ich den Benutzer zu https://discourse.fqdn.top/session/sso_login?sso=PAYLOAD&sig=SIGNATURE umleite und force_https auf false steht. Das zeigt, dass sowohl der SSO-Teil als auch der Proxy perfekt funktionieren. Erst wenn ich force_https auf true umstelle, funktioniert es nicht mehr. Wenn ich eine bestehende Sitzung habe, kann ich force_https auf true setzen und Discourse ohne Probleme nutzen (was die These weiter untermauert, dass das Problem nichts mit dem Reverse-Proxy zu tun hat). force_https auf false zu lassen, ist keine Option, da dies Logos beschädigt und Chrome nicht glücklich macht, wenn Ressourcen von HTTP und HTTPS gemischt werden (es zeigt eine kleine Warnung in der Adressleiste an, dass die Seite nicht sicher ist).
Wie sieht deine nginx-Konfiguration aus und hast du einen X-Forwarded-Proto-Header darin?
Vielen Dank. Ja, das hat das Problem gelöst. Es war also mit dem Proxy verbunden. Entschuldigung, dass ich das Gegenteil angenommen habe, nur weil der Inhalt geladen wurde.
Der Vollständigkeit halber verwende ich Apache als Reverse-Proxy und nicht nginx. Hier sind die relevanten Konfigurationszeilen:
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://[::1]:2045/ retry=10
ProxyPassReverse / http://[::1]:2045/
Das Hinzufügen der ersten Zeile hat das Problem gelöst.
Hallo zusammen,
es tut mir leid, das nochmal anzusprechen, aber ich bekomme meine Mixed-Content-Warnungen in Firefox einfach nicht los. Das Lustige ist, dass ich eigentlich fast das gleiche Setup habe … mehr oder weniger. Vielleicht kann ja jemand ein paar Ideen oder Verbesserungsvorschläge einbringen. Ich bin nicht gerade ein Experte für Apache-Direktiven, aber es ergibt für mich zumindest einen gewissen Sinn.
Wir betreiben Discourse in Docker hinter einem Apache-Reverse-Proxy und verwalten die Lets-Encrypt-Zertifikate mit ISPConfig, da wir viele „normale
Versuche SiteIconManager.ensure_optimized! in einer Rails-Konsole.
Wow, so eine schnelle Antwort! Vielen Dank.
In der Zwischenzeit … ich weiß nicht, ob es dadurch ausgelöst wurde, dass etwas Zeit verging, bis etwas passierte. Aber nachdem ich meinen ersten Beitrag eingereicht hatte, habe ich diese beiden Bilder (Favicon und Apple-Icon) erneut hochgeladen – diesmal nicht über den Assistenten, sondern über die Admin-Einstellungen (Branding). Genau in diesem Moment wollte ich den Tab schließen, nur um kurz zu prüfen, ob die Anmeldung und alles andere jetzt korrekt funktioniert … ratet mal. Die Firefox-Mixed-Content-Fehler waren verschwunden!
Wow!
Trotzdem noch einmal vielen Dank an @RGJ. Ich vermute, das würde auch das Neu-Rendering der optimierten Bilder beheben. Meinst du, es wurde in der Zwischenzeit durch einen Zeit-Schwellenwert ausgelöst oder durch das erneute Hochladen der Bilder über das Admin-Panel und nicht über den Assistenten?
Nochmals vielen Dank, besonders an @alphanoob1337, dass ihr das endlich zum Laufen gebracht habt!
Wow, das ist ziemlich unangenehm für einen Montag, aber ich gehe jetzt mit einem angenehmen, glücklichen Gefühl vom Schreibtisch 