Hallo zusammen,
wir haben eine Discourse-Instanz, die in einem iFrame innerhalb unserer Anwendung eingebettet ist, und das funktioniert soweit gut. Wenn jedoch ein nicht authentifizierter Benutzer versucht, auf eine Seite zuzugreifen, zu der er keinen Zugriff hat (entweder nicht vorhanden oder gruppenbeschränkt), enthält die Antwort nun mysteriöserweise X-Frame-Options: SAMEORIGIN, und Browser blockieren das Rendern des Frames.
Ich habe verschiedene Versionen überprüft, beginnend mit 3.3.1 stable bis hin zu fast dem aktuellen Stand (zuletzt getestet Mitte letzter Woche).
Es läuft auf einer anderen Subdomain als die Hauptanwendung und ist für das Einbetten mit allow_embedding_site_in_an_iframe: true konfiguriert. Durch Debugging einer sauberen Instanz habe ich festgestellt, dass in einem solchen Fall die Methode conditionally_allow_site_embedding in ApplicationController nicht aufgerufen wird, wodurch der Header in der Antwort verbleibt (GH-Link). Ich habe verfolgt, dass dies zu einem Fehler führt und somit den Ablauf unterbricht.
Reproduktion:
- Führen Sie eine saubere Instanz von Discourse aus (oder jede Instanz) und konfigurieren Sie sie mit
allow_embedding_site_in_an_iframe: true. - Betten Sie sie in einem iFrame auf einer über HTTPS bereitgestellten Website mit einem nicht existierenden Pfad ein, um einen 404-Fehler auszulösen.
Erwartet: Browser erlaubt die Anzeige von Discourse.
Tatsächlich: Browser verhindert die Anzeige von Discourse aufgrund von X-Frame-Options: SAMEORIGIN in der Antwort.
Nebenbemerkung: Es läuft über eine reine DNS-Cloudflare und wir haben versucht, den Header im Proxy-Modus zu löschen. Wir können es jedoch nicht in den Proxy-Modus versetzen, da CF Cookies herausfiltert, die für unsere benutzerdefinierte SSO-Implementierung erforderlich sind. Dies ist also derzeit keine Option für uns.