That was!! You save my day… Thanks a lot!
Could be wrong, but doesn’t this open up a x-site security vulnerability? See:
I don’t know much in these matters, but here is my reasoning:
- “same site cookie” is enabled by default, so it is probably much better this way.
- “same site cookie” can be disabled, so it’s probably not a security hole by itself, rather a weakness that could be exploited in conjunction with others. Disable it at your own risks.
Anyone understands why disabling same site cookie enforcement prevents users from log in within an iframe?
Possiamo avere per favore il supporto ufficiale per Discourse in un iframe?
EDIT: Ops, scusate, non avevo realizzato che stavo pubblicando due anni dopo.
È molto improbabile che ciò verrà mai supportato.
Jeff,
Prima di tutto: Discourse è fantastico e grazie per averlo creato!
Seconda cosa: esiste una documentazione che elenchi i problemi specifici che ci si aspetta con un Discourse incorporato tramite iframe, o quali limitazioni lo influenzerebbero in linea di principio?
Grazie!
Ciao Adam, è passato un po’ di tempo, provo a rispondere qui.
Utilizzare un <iframe> è molto soggetto a errori e renderebbe Discourse molto difficile da usare, pieno di bug difficili da individuare. Inoltre, tende a creare una “finestra” all’interno di Discourse, causando problemi in funzionalità come lo scorrimento di discussioni lunghe. In sostanza, gli iframe isolano molte delle funzionalità di Discourse.
Una buona strada da percorrere, se stavi valutando l’uso di un iframe, sarebbe aggiungere un’intestazione al tuo forum che corrisponda al resto del tuo sito/app/portale, inclusi i link di navigazione. Quando un utente clicca per entrare nel forum, vedrà una navigazione simile, ma si troverà su un URL diverso ospitato altrove. Quando clicca su un link non relativo al forum nell’intestazione, tornerà nel sito/app/portale.
Spero che questo ti sia d’aiuto.
Grazie per la tua risposta!
Potresti condividere quali sono i problemi specifici che ci si aspetta? O le ragioni specifiche per cui il contesto di un iframe causerebbe gravi problemi?
Cosa significa “finestrare” in questo caso?
Questo è ciò che faremo per la nostra area principale di discussione, ma è problematico per questo caso d’uso specifico. Stiamo gestendo corsi online. Ogni corso si svolge in un’area privata e con tema specifico del nostro sito. Il contenuto del corso include materiali didattici, video, programma e un’area di discussione. Una volta completato il corso, gli studenti possono continuare le discussioni che hanno avviato con gli altri partecipanti dello stesso gruppo. Vengono inoltre aggiunti a un gruppo di discussione generale per gli ex studenti del corso e saranno invitati al nostro forum pubblico più ampio.
Per il nostro caso d’uso, ci sono due problemi con l’approccio suggerito qui:
-
Il tema (intestazione, stili, barra laterale, ecc.) dell’area del corso sul nostro sito non è lo stesso che vorremmo utilizzare per il nostro Discourse in generale. Per adattarsi a ciò, dovremmo essere in grado di utilizzare stili e contenuti del tema diversi per categoria, il che non sembra possibile.
-
La discussione del corso nella nostra attuale implementazione (non basata su Discourse) include stili, intestazione e un menu laterale. È uno spazio a bassa distrazione dove gli studenti possono concentrarsi sul contenuto del corso e passare fluidamente tra discussione, materiali didattici, video, ecc. Per quanto ne so, sarebbe difficile modificare Discourse per replicare questo tipo di ambiente immersivo. Se non è così, sono felice di essere corretto!
Grazie per il tuo aiuto,
Adam
È possibile. L’elemento body avrà una classe che indica la categoria corrente, permettendoti di delimitare facilmente il tema utilizzando selettori nidificati in SCSS.
In generale, ti consiglio di aggiungere alcuni widget di Discourse all’area del corso, come la nostra funzione supportata per l’elenco dei topic in iframe, documentata in Incorporare un elenco di topic di Discourse in un altro sito. In questo modo, gli studenti potranno vedere un elenco delle discussioni più recenti relative alla pagina del loro corso corrente e, con un solo clic, unirsi a esse in un’altra scheda del browser!
Ciao Falco,
Grazie per la tua risposta e scusa il ritardo nella mia.
Purtroppo, la nostra implementazione dei corsi è un po’ più complessa di quanto un ambito CSS personalizzato possa gestire senza sforzi eccessivi. Ad esempio, il menu dell’intestazione include un menu a tendina con i corsi in cui è iscritto l’utente corrente. Questo viene generato dinamicamente dal database di WordPress in base all’utente collegato, quindi sarebbe difficile replicarlo in Discourse.
Il menu laterale nell’area dei corsi include collegamenti a vari tipi di contenuti dei corsi, specifici per un determinato corso. Se ho capito bene, affinché quanto da te descritto funzioni, tutti questi contenuti, per tutti i corsi, dovrebbero essere inseriti manualmente nel tema e poi mostrati o nascosti tramite CSS in base alla classe del body. È corretto?
Un approccio che potrebbe funzionare sarebbe utilizzare un po’ di JavaScript lato client in Discourse che recuperi i contenuti dalla nostra API e li visualizzi. È possibile aggiungere script personalizzati che eseguano XmlHttpRequest verso altri server? Vedi qualche motivo per cui questo non sarebbe possibile?
Spero ancora di ricevere una risposta a questa domanda.
Grazie!
Sì, è possibile. Fai solo attenzione a non far bloccare il rendering della pagina da quelle richieste.