È possibile utilizzare l'embed dell'app completa su un altro dominio?

[Dev-in-the-BM]

Sto usando un forum Discourse come sezione commenti per il mio blog, che si trova su un dominio diverso.

Sto cercando di utilizzare l’embed dell’app completa di Discourse, ma gli utenti non possono accedere, rispondere o interagire in alcun modo dall’embed.

Quando qualcuno prova a rispondere, viene reindirizzato alla pagina di accesso, anche se è già loggato.

Effettuare l’accesso lì non aiuta.

Sembra che il problema sia legato ai cookie cross-site.

Esiste una soluzione?

C’è una correzione?

---

Scusa, non sono molto familiare con tutte queste cose relative ai cookie, quindi ho usato l’IA per capire cosa sta succedendo e cercare possibili soluzioni.

Se non ti piace l’IA, puoi fermarti qui.

Ho riportato di seguito ciò che ho ottenuto da loro, ma questo post stesso, inclusa tutta la formattazione, è stato scritto utilizzando la mia Intelligenza Naturale.

Come Gemini ha riassunto il problema.

@Gemini

L’embed “Full App” non riesce a riconoscere le sessioni utente attive quando il forum e il sito utilizzano domini diversi.

Questo accade perché il browser tratta il forum incorporato come un tracciatore di terze parti.

I browser moderni bloccano i cookie di terze parti per impostazione predefinita per proteggere la privacy degli utenti.

I cookie di sessione di Discourse sono impostati su SameSite=Lax.

I browser non inviano i cookie Lax all’interno di un iframe se il dominio padre è diverso.

Poiché i cookie vengono bloccati, il forum non può vedere i dati di accesso dell’utente.

L’embed passa automaticamente alla modalità “Ospite” e apre una nuova scheda quando l’utente tenta di interagire.

Soluzioni ovvie come l’aggiunta del host alle impostazioni di Discourse non funzionano.

L’aggiunta alla whitelist dice solo a Discourse di consentire la connessione; non può sovrascrivere le regole di sicurezza del browser.

Aggiornare la pagina o accedere di nuovo in una nuova scheda non funziona perché il blocco a livello di browser rimane attivo per l’iframe.

L’embed rimane essenzialmente intrappolato in una sandbox senza cookie.

Sembra che ci siano modi corretti per farlo, ma Discourse dovrebbe implementarli.

@Google Search AI Mode

Sì, esistono metodi ufficiali e sicuri, ma il “vecchio modo” (impostare semplicemente un cookie) è morto. ^[1]

Per mantenere un accesso in un iframe oggi, devi utilizzare uno dei seguenti tre standard “ufficiali” dei browser. Quale scegliere dipende interamente da chi deve vedere la sessione di accesso.

1. Il metodo “Barattolo Privato”: CHIPS

Ideale per: Widget di chat, mappe incorporate o moduli di pagamento che devono rimanere loggati solo su questo specifico sito padre.

• Come funziona: Imposti un cookie con l’attributo Partitioned.

  • Set-Cookie: session_id=xyz; Secure; SameSite=None; Partitioned;

• Il risultato: Il browser crea un “barattolo dei cookie” unico per il tuo iframe, associato a (Tuo Dominio + Dominio della Pagina Padre).

• Pro: Funziona automaticamente senza chiedere il permesso all’utente.

• Contro: La sessione non è condivisa. Se l’utente visita il tuo sito direttamente in una nuova scheda, non sarà loggato lì. È loggato solo all’interno di quel contesto di embed specifico. ^[2]

2. Il metodo “Sessione Condivisa”: Storage Access API (SAA)

Ideale per: Quando hai bisogno che l’iframe veda la stessa sessione di accesso della scheda principale dell’utente (ad esempio, un widget “Commenta come [Utente]”). ^[3]

• Come funziona: L’iframe non può leggere i propri cookie inizialmente. Deve chiamare un’API JavaScript specifica per richiedere l’accesso:

document.requestStorageAccess().then(() => {
  // Ora puoi leggere i tuoi cookie cross-site!
});

• Il problema: Questo richiede un gesto dell’utente (come un clic). In genere devi prima renderizzare un pulsante “Clicca per connetterti”. Una volta cliccato, il browser potrebbe chiedere all’utente (“Consenti a [iframe] di usare i cookie?”).
• Pro: Concede l’accesso ai tuoi “veri” cookie globali.
• Contro: Alta frizione; richiede interazione dell’utente/popup. ^[4][5]

3. Il metodo “Passaggio del Token” (Il più comune)

Ideale per: Applicazioni SaaS che incorporano i propri strumenti nei dashboard dei clienti.

• Come funziona: Non fai affidamento sui cookie dell’iframe.

  1. La pagina padre gestisce l’accesso (o ha già il token).
  2. La pagina padre passa il token di autenticazione (JWT) all’iframe tramite postMessage.
  3. L’iframe riceve il token e lo memorizza in memoria (o in sessionStorage) per allegarlo alle richieste API.

• Pro: Zero dipendenza dalle politiche dei cookie del browser; completamente compatibile tra browser.

• Contro: Richiede modifiche al codice sia sulla pagina padre che sul sito dell’iframe. ^[6]

Raccomandazione Riassuntiva

Se hai bisogno di… [4:1][7][8]	Usa…
Accesso isolato (Lo stato del widget non deve corrispondere al sito principale)	CHIPS (Cookie Partitioned)
Accesso globale (L’utente è già loggato sul tuo sito altrove)	Storage Access API
Controllo (Possiedi sia il sito padre che l’iframe)	Passaggio del Token (postMessage)

---

1. https://developer.mozilla.org ↩︎

2. https://help.boldbi.com ↩︎

3. https://developers.google.com ↩︎

4. https://privacysandbox.google.com ↩︎ ↩︎

5. https://learn.microsoft.com ↩︎

6. https://www.blackduck.com ↩︎

7. https://developer.mozilla.org ↩︎

8. https://stackoverflow.com ↩︎

[Lilly (Lillian)]

@Dev-in-the-BM

Sto cercando di utilizzare l’embed dell’app completa di Discourse, ma gli utenti non possono accedere, rispondere o interagire in alcun modo dall’embed.

Quando qualcuno tenta di rispondere, viene reindirizzato alla pagina di accesso, anche se è già loggato.

Il tuo Discourse è aggiornato? Assicurati di aggiornare all’ultima versione. Io non ho problemi a rispondere quando sono loggato nel forum corretto.

Rispondere come anonimo apre una nuova scheda per il login, come spiegato qui:

@Falco

@Heliosurge

Se un visitatore non ha un account, verrà invitato a crearne uno?

Sì, viene aperta una nuova scheda per il login.

[Falco]

Accedi alla console di Rails e imposta il cookie del sito sullo stesso valore su “Nessuno”.

cd /var/discourse
./launcher enter app
rails c
SiteSetting.same_site_cookies = "None"

[Dev-in-the-BM]

@Lilly

Il tuo Discourse è aggiornato?

Sì.

@Lilly

Non ho problemi a rispondere quando sono loggato nel forum corretto.

Nello stesso dominio o tra siti diversi?

@Lilly

Rispondere come anonimo apre una nuova scheda per il login, come spiegato qui:

@Dev-in-the-BM

Quando qualcuno prova a rispondere, viene reindirizzato per accedere su una nuova pagina, anche se è già loggato.

Accedere lì non aiuta.

[Dev-in-the-BM]

@Falco

Entra nella console Rails e imposta lo stesso cookie del sito su none.

Ci ho pensato, ma è molto insicuro, ovviamente non è una buona idea.

[NateDhaliwal]

@Dev-in-the-BM

Ci ho pensato, ma è molto insicuro, ovviamente non è una buona idea.

Solo una nota: la persona che ha suggerito quella soluzione è stata proprio quella che ha contribuito a realizzare la funzione .

[RGJ (Richard - Communiteq)]

@Dev-in-the-BM

Ci ho pensato, ma è molto insicuro, ovviamente non è una buona idea.

L’incorporamento cross-domain non è sempre la scelta migliore, ma dai.