Ich habe mittlerweile Discourse-Server in etwa 5 Instanzen eingerichtet, und alle zeigen seltsames Verhalten. Ich bin mir nicht sicher, ob es sich tatsächlich um einen Fehler handelt oder ob andere bereits ähnliche Erfahrungen gemacht haben.
Schritte zur Reproduktion
Die Servereinrichtung verläuft reibungslos.
Der Einrichtungsassistent funktioniert einwandfrei; alle Bilder werden hochgeladen und wie erwartet angezeigt.
Der Benutzer erhält einen Anmeldelink, klickt darauf, und die Registrierung verläuft problemlos.
(Hier beginnen die Probleme) Der Benutzer meldet sich an, und die Website-Logos sind alle defekt – es werden nur die Texttitel angezeigt.
Der Benutzer kann kein benutzerdefiniertes Avatar hochladen oder zuweisen.
Das Site-Zertifikat meldet, dass die Website nicht sicher ist.
Aus irgendeinem Grund betrifft dies NUR den Browser, der für die Anmeldung verwendet wurde, und tritt in Chrome mit einer deutlich höheren Fehlerrate auf.
Fehlerbehebung
Wir haben den Benutzern geraten, Browser-Cache und Cookies zu leeren – trotzdem funktioniert es nicht.
Wir haben die Benutzer gebeten, ihre Browser (meist Chrome) neu zu installieren – trotzdem funktioniert es nicht.
Wir haben die Benutzer gebeten, eine alternative Identität in Chrome zu verwenden oder einen anderen Browser (Safari, Firefox usw.) zu nutzen – das funktioniert!
Wir haben absolut keine Ahnung, warum der letzte Punkt funktioniert und warum die ursprüngliche Anmeldedaten-ID gestört ist. Es wäre nicht tragbar, unsere Benutzer (etwa 600–700) zu bitten, sich aus ihrer Chrome-Identität abzumelden und erneut anzumelden – falls dies tatsächlich die Lösung ist.
Ist es eine Standard-Installation von 30 Minuten? Oder gibt es hier etwas Besonderes?
Haben Sie force_https in den Site-Einstellungen aktiviert, um zu prüfen, ob das Problem damit behoben wird?
Ich kann Ihre Schritte in meiner Sandbox auf dem neuesten Zweig nicht nachvollziehen. Es wäre daher sehr hilfreich, wenn Sie einen Link zu einer der betroffenen Instanzen teilen könnten.
Okay. Alle Installationsinstanzen erhalten ihr Zertifikat von einem Reverse-Nginx-Proxy, der NICHT auf derselben Maschine läuft. Wird force_https dann noch einen Unterschied machen?
Das ist also keine Standardinstallation. Sie sagten, es sei eine.
Wenn Discourse hinter einem korrekt konfigurierten Reverse-Proxy läuft, macht force_https definitiv einen Unterschied. Die Einstellung weist Discourse im Wesentlichen an, alle Ressourcen und Assets über HTTPS zu laden.
Das hat es, btw. Sperr mich aus. Die Aktivierung von force_https hat das Bildproblem behoben, aber es unmöglich gemacht, sich von Browsern mit einer neuen Sitzung aus zu authentifizieren. Bestehende Sitzungen funktionieren, aber sobald man sich abmeldet, kann man nicht mehr zurück.
Da ist etwas mit deinem Reverse Proxy nicht in Ordnung. Du musst dessen Konfiguration überprüfen, um sicherzustellen, dass alles korrekt eingerichtet ist.
Habe ich gerade. Ich habe im Server-Block bereits alles so eingerichtet, wie es der Artikel vorschlägt. Das ist wahrscheinlich der Grund, warum Sitzungen in alternativen Profilen/Browsern nach der ersten Anmeldung/Authentifizierung normal funktionieren.
Das einzige Element, bei dem meine Konfiguration abweicht, ist, dass ich keine templates.yml verwende.
Das wird noch eine ganze Menge weiterer Untersuchungen erfordern.
Das könnte am Browser-Cache oder an einem falsch konfigurierten Zertifikat liegen. Haben Sie ein Let’s Encrypt-SSL oder ein anderes Zertifikat erhalten?
Nein. Keine externe Authentifizierung. Habe den Inkognito-Modus versucht. Kein Erfolg. Gleiches Ergebnis.
Es muss etwas im Server-Block sein. Ich werde das später etwas genauer untersuchen.