UPDATE: Gelöst!
Um das Problem zu lösen, konnte ich force_https aktivieren, was alles für uns gelöst hat. Es stellte sich heraus, dass Passkeys versuchten, zu http:// zu leiten, aber dieser gemischte Datenverkehr wurde vom Browser nicht gekennzeichnet. Wie sich herausstellte, war Cloudflare überhaupt nicht das eigentliche Problem. Ich hoffe, das hilft jemandem in Zukunft.
Ursprünglicher Beitrag:
Das Problem
Hallo! Ich habe meine Discourse-Instanz kürzlich hinter einem Cloudflare-Tunnel verschoben, und es scheint, dass alles gut funktioniert, mit Ausnahme von Passkeys. Sowohl bestehende als auch neue Passkey-Registrierungen schlagen fehl, aber ich glaube nicht, dass die Protokolle sehr klar machen, WARUM es fehlschlägt. Ich hoffe, jemand hier kann mir helfen, die restlichen Fehlerbehebungsinformationen zu finden, die ich zur Lösung dieses Problems benötige:
Relevante Informationen
Über mein Setup
- Verwende Discourse Docker, um Discourse bereitzustellen.
- Postgres und Redis sind extern bereitgestellt.
- Bereitgestellt auf Ubuntu auf einer AWS EC2-Instanz.
- Wie bereits erwähnt, stellt der Cloudflare-Tunnel TLS bereit und fungiert als Proxy.
Was ich versucht habe
- Ich habe meine Konfiguration überprüft, um sicherzustellen, dass Discourse den Hostnamen meines Forums (
forums.example.com) erwartet. - Discourse wurde für Port 80 HTTP konfiguriert, da Cloudflare TLS handhabt.
- Als HTTP nicht erfolgreich war, versuchte ich, Discourse zu zwingen, nur SSL zu verwenden, indem ich ein selbstsigniertes Zertifikat bereitstellte und Cloudflare auf Port 443 über das HTTPS-Protokoll an Discourse weiterleitete.
- Ich habe sichergestellt, dass Cloudflare
forums.example.coman meine Website weiterleitet. Ich weiß, dass es das tut, da jeder andere Host-Header Discourse’s NGINX zu einem 404-Fehler veranlasst.
Relevante Protokolle
- Dieser Teil ist etwas knifflig. Discourse liefert serverseitig nichts (soweit ich gesehen habe), und egal ob ich Bitwarden, iCloud Keychain, Chrome oder Firefox verwende, das Ergebnis ist dasselbe.
- Protokolle für den Passkey selbst sind fast nicht vorhanden.
- Das Nützlichste, was ich in der Entwicklerkonsole von Firefox / Chrome gefunden habe, als ich versuchte, einen neuen Passkey zu erstellen, war Folgendes:
{
"errors": [
"The origin of the authentication request does not match the server origin."
]
}
Dies ist ein ziemlich klares Indiz dafür, dass etwas zwischen dem Client und Discourse (auch bekannt als Proxy) schief läuft, aber diese Protokolle geben keine Auskunft darüber, welche Informationen ausgetauscht werden, um dies weiter zu untersuchen.
Kann mir jemand helfen, andere Einstellungen oder Protokollspeicherorte zu finden, die ich überprüfen kann, oder hat jemand andere Empfehlungen zur Fehlerbehebung? Ich halte es für unwahrscheinlich, aber ich nehme an, ein Fehler in der Nginx-Konfiguration könnte ebenfalls eine Rolle spielen. Ich habe im Wesentlichen einen doppelten Proxy zwischen dem Client und Discourse, mit sowohl CloudFlare als auch Nginx im Einsatz. Sollte ich irgendeinen Teil dieses Setups überdenken?
Was die Priorität angeht, ist es sicherlich schön, wenn es behoben ist, aber da nur etwa 8 von einigen tausend Benutzern Passkeys verwenden (während andere Anmeldemethoden einwandfrei funktionieren), mache ich mir darüber nicht allzu viele Sorgen.