Abbiamo Discourse installato su site1. Possediamo/amministriamo site2.tld e vogliamo accedere al forum tramite un iFrame da una pagina lì. Non sono esperto nell’arte del CSP-fu, quindi l’assistenza è apprezzata.
Non voglio disabilitare le restrizioni sugli antenati, ma temporaneamente, ho deselezionato il CSP frame ancestor:
Firefox non può aprire questa pagina
Per proteggere la tua sicurezza, forum.site1.org non consentirà a Firefox di visualizzare la pagina se un altro sito l’ha incorporata. Per visualizzare questa pagina, devi aprirla in una nuova finestra.
Ho guardato Embedding ma quella funzionalità sembra servire a uno scopo diverso. Non vogliamo limitare a un singolo argomento e l’utente non sarà loggato. Inizialmente va bene se l’utente non effettua il login e l’intero forum è disponibile in sola lettura.
Sconsigliamo, né testiamo, l’utilizzo di Discourse completamente incorporato in un altro sito tramite iframe.
Invece, consigliamo di avere ogni sito sul proprio dominio, utilizzando collegamenti, single sign-on e stilizzando Discourse per abbinare l’aspetto visivo del tuo sito principale.
Comprendendo le conseguenze a lungo termine, abbiamo temporaneamente disabilitato CSP ma riceviamo comunque un avviso CSP da Firefox. È necessario un riavvio?
Ecco l’applicazione/sfida. Forse c’è una soluzione semplice…
C’è un server Discourse e, come al solito, un numero qualsiasi di account utente e ospiti. Gli utenti registrati hanno un’app che ospita un webserver locale. Una pagina web viene creata in questa app e acceduta dal browser locale come http://192.168.1.1:8080. Tale pagina web offre il forum tramite un IFrame.
Non abbiamo controllo sulle sottoreti che servono il contenuto, quindi l’IP può provenire da qualsiasi NAT/DHCP comune. Ma abbiamo il pieno controllo su quanto segue:
L’installazione e il server Discourse.
Il contenuto che viene servito.
La porta è generalmente 8080, configurabile dall’utente, ma non sarà mai 80 o 443.
Poiché si tratta di contenuto locale e non critico per la missione, non è protetto da SSL.
Gli utenti devono avere un account Discourse e devono accedere a Discourse per l’accesso in scrittura.
Per quanto riguarda la sicurezza:
Il forum pubblico è accessibile via rete tramite hostname.
L’accesso alla rete è ovviamente sempre protetto da SSL.
Nessuno può creare contenuti del forum se non è loggato.
Quindi sì, la pagina locale con l’IFrame viene servita come HTTP: ma la sorgente dell’IFrame è HTTPS://forum.site.tld. (Questa differenza di protocollo potrebbe essere la causa del fallimento nell’accesso al forum anche con CSP disabilitato.)
Una volta che l’utente avvia il browser, per accedere al server locale deve inserire una password. Potremmo abilitare SSL per quella pagina se necessario, al fine di mantenere la coerenza tra quella pagina ancestrale e l’IFrame del sito del forum abilitato per SSL.
Non abbiamo intenzione di eseguire script tramite l’IFrame in Discourse. Tutto ciò che vogliamo fare è ospitare il forum in un container.
Ecco alcune idee casuali che potrebbero non avere alcun valore:
Consentire agli utenti di ottenere una chiave API dalla loro pagina dell’account Discourse, che possono inserire nell’app, che verrà quindi passata a Discourse in un cookie o in qualche altro modo. Questo conferma che, sebbene l’utente non sia conforme a CORS o CSP, ha l’autorizzazione per accedere alle risorse.
Far iniettare dall’app un token nell’URI dell’IFrame verso Discourse. Contemporaneamente, utilizzare una chiamata API per far sì che Discourse consenta connessioni in entrata con quel token. (Sì, questo dovrebbe essere codificato)
Diventando ancora più imbarazzante… Creare una pagina su un sito della community che apra un IFrame per il contenuto della sottorete e un altro IFrame per il forum. Questo sito può essere autorizzato per l’accesso cross-origin.
Rinunciare a cercare di aggirare le policy e utilizzare target=window per aprire Discourse al di fuori della finestra dell’applicazione.
Senza ricorrere immediatamente all’opzione 4… qualche idea? Grazie!
