Ciao a tutti,
Abbiamo un’istanza di Discourse incorporata in un iframe all’interno della nostra applicazione, e funziona bene così com’è. Tuttavia, quando un utente non autenticato tenta di accedere a una pagina a cui non ha accesso (che non esiste o è limitata a un gruppo), la risposta ora include misteriosamente X-Frame-Options: SAMEORIGIN e i browser bloccano il rendering del frame.
Ho controllato diverse versioni a partire dalla 3.3.1 stable fino quasi all’ultima versione bleeding edge (ultima testata a metà della scorsa settimana).
È in esecuzione su un sottodominio diverso dall’app principale ed è configurato per l’incorporamento con allow_embedding_site_in_an_iframe: true e, eseguendo il debug di un’istanza pulita, ho notato che in tal caso il metodo conditionally_allow_site_embedding in ApplicationController non viene chiamato, lasciando così l’header nella risposta (link GH), e ho tracciato che lancia un’eccezione a un certo punto, interrompendo così il flusso.
Riproduzione:
- Esegui un’istanza pulita di Discourse (o qualsiasi istanza in realtà – questo è successo in ambienti locali, di test e di produzione) e configurala con
allow_embedding_site_in_an_iframe: true. - Incorporala in un iframe in un sito web servito tramite HTTPS utilizzando un percorso inesistente per attivare un errore 404.
Atteso: Il browser consente a Discourse di eseguire il rendering.
Effettivo: Il browser impedisce a Discourse di eseguire il rendering a causa di X-Frame-Options: SAMEORIGIN presente nella risposta.
Nota a margine: è in esecuzione tramite un Cloudflare solo DNS e abbiamo provato a eliminare l’header in modalità proxy, tuttavia, non possiamo metterlo in modalità proxy poiché CF filtra i cookie che sono necessari per la nostra implementazione SSO personalizzata, quindi questa non è un’opzione per noi al momento.