Est-il possible d'utiliser l'intégration complète de l'application sur un autre domaine ?

[Dev-in-the-BM]

J’utilise un forum Discourse comme section de commentaires pour mon blog, qui se trouve sur un domaine différent.

J’essaie d’utiliser l’intégration complète de l’application Discourse, mais les utilisateurs ne peuvent pas se connecter, répondre ou interagir du tout depuis l’intégration.

Lorsqu’un utilisateur tente de répondre, il est redirigé vers une page de connexion, même s’il est déjà connecté.

Se connecter sur le forum ne résout pas le problème.

Il semble que ce soit un problème de cookies intersites.

Y a-t-il une solution ?

Une correction possible ?

---

Désolé, je ne suis pas vraiment familier avec tout ce qui concerne les cookies, alors j’ai utilisé une IA pour comprendre ce qui se passe et rechercher des solutions possibles.

Si vous n’aimez pas l’IA, vous pouvez vous arrêter ici.

Voici ce que j’ai obtenu d’elle, mais ce post lui-même, y compris tout le formatage, a été rédigé en utilisant mon Intelligence Naturelle.

Comment Gemini a résumé le problème.

@Gemini

L’intégration « Full App » ne parvient pas à reconnaître les sessions utilisateurs actives lorsque le forum et le site utilisent des domaines différents.

Cela se produit parce que le navigateur traite le forum intégré comme un traqueur tiers.

Les navigateurs modernes bloquent par défaut les cookies tiers pour protéger la vie privée des utilisateurs.

Les cookies de session de Discourse sont configurés avec SameSite=Lax.

Les navigateurs n’envoient pas les cookies Lax à l’intérieur d’une iframe si le domaine parent est différent.

Comme les cookies sont bloqués, le forum ne peut pas voir les données de connexion de l’utilisateur.

L’intégration bascule par défaut en mode « Invité » et ouvre un nouvel onglet lorsque l’utilisateur tente d’interagir.

Les corrections évidentes, comme l’ajout du hôte à la liste blanche dans les paramètres de Discourse, ne fonctionnent pas.

La liste blanche indique seulement à Discourse d’autoriser la connexion ; elle ne peut pas outrepasser les règles de sécurité du navigateur.

Actualiser la page ou se reconnecter dans un nouvel onglet échoue également car le blocage au niveau du navigateur reste actif pour l’iframe.

L’intégration reste essentiellement piégée dans un bac à sable sans cookies.

Il semble qu'il existe des façons correctes de faire cela, mais Discourse devrait les mettre en œuvre.

@Google Search AI Mode

Oui, il existe des méthodes officiellement prises en charge et sécurisées, mais la « vieille méthode » (simplement définir un cookie) est obsolète. ^[1]

Pour maintenir une connexion dans une iframe aujourd’hui, vous devez utiliser l’une des trois normes « officielles » des navigateurs suivantes. Le choix dépend entièrement de qui doit voir la session de connexion.

1. La méthode du « Bocal Privé » : CHIPS

Idéal pour : Les widgets de chat, les cartes intégrées ou les formulaires de paiement qui doivent rester connectés uniquement sur ce site parent spécifique.

• Fonctionnement : Vous définissez un cookie avec l’attribut Partitioned.

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

• Résultat : Le navigateur crée un « bocal à cookies » unique pour votre iframe, lié à (Votre Domaine + Domaine de la Page Parente).

• Avantages : Cela fonctionne automatiquement sans demander la permission à l’utilisateur.

• Inconvénients : La session n’est pas partagée. Si l’utilisateur visite votre site directement dans un nouvel onglet, il ne sera pas connecté là-bas. Il est uniquement connecté dans ce contexte d’intégration spécifique. ^[2]

2. La méthode de la « Session Partagée » : Storage Access API (SAA)

Idéal pour : Lorsque vous avez besoin que l’iframe voie la même session de connexion que l’onglet principal de l’utilisateur (par exemple, un widget « Commenter en tant que [Utilisateur] »). ^[3]

• Fonctionnement : L’iframe ne peut pas lire ses propres cookies initialement. Elle doit appeler une API JavaScript spécifique pour demander l’accès :

document.requestStorageAccess().then(() => {
  // Maintenant, vous pouvez lire vos cookies intersites !
});

• Le hic : Cela nécessite une action de l’utilisateur (comme un clic). Vous devez généralement afficher un bouton « Cliquez pour vous connecter » en premier. Une fois cliqué, le navigateur peut demander à l’utilisateur (« Autoriser [iframe] à utiliser les cookies ? »).
• Avantages : Accorde l’accès à vos « vrais » cookies globaux.
• Inconvénients : Forte friction ; nécessite une interaction de l’utilisateur/ des pop-ups. ^[4][5]

3. La méthode du « Transfert de Jeton » (La plus courante)

Idéal pour : Les applications SaaS intégrant leurs propres outils dans les tableaux de bord clients.

• Fonctionnement : Vous ne vous fiez pas du tout aux cookies de l’iframe.

  1. La page parente gère la connexion (ou possède déjà le jeton).
  2. La page parente transmet le jeton d’authentification (JWT) à l’iframe via postMessage.
  3. L’iframe capture le jeton et le stocke en mémoire (ou dans sessionStorage) pour l’attacher aux requêtes API.

• Avantages : Aucune dépendance aux politiques de cookies du navigateur ; entièrement compatible entre tous les navigateurs.

• Inconvénients : Nécessite des modifications de code à la fois sur la page parente et sur le site de l’iframe. ^[6]

Recommandation de synthèse

Si vous avez besoin de… [4:1][7][8]	Utilisez…
Connexion isolée (L’état du widget n’a pas besoin de correspondre au site principal)	CHIPS (Cookies Partitionnés)
Connexion globale (L’utilisateur est déjà connecté à votre site ailleurs)	Storage Access API
Contrôle (Vous possédez à la fois le site parent et l’iframe)	Transfert de Jeton (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

J’essaie d’utiliser l’intégration de l’application Discourse, mais les utilisateurs ne peuvent pas se connecter, répondre ou interagir du tout depuis l’intégration.

Lorsqu’un utilisateur essaie de répondre, il est redirigé vers une page de connexion, même s’il est déjà connecté.

Votre Discourse est-il à jour ? Assurez-vous de mettre à jour vers la dernière version. Je n’ai aucun problème pour répondre lorsque je suis connecté au bon forum.

Répondre en tant qu’anonyme ouvre un nouvel onglet pour se connecter, comme expliqué ici :

@Falco

@Heliosurge

Si un visiteur n’a pas de compte, cela lui proposera-t-il d’en créer un ?

Oui, cela ouvre un nouvel onglet pour la connexion.

[Falco]

Entrez dans la console Rails et définissez le cookie de site identique sur None.

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

[Dev-in-the-BM]

@Lilly

Votre Discourse est-il à jour ?

Oui.

@Lilly

Je n’ai aucun problème pour répondre lorsque je suis connecté au bon forum.

Sur le même domaine ou sur des sites différents ?

@Lilly

Répondre en tant qu’anonyme ouvre un nouvel onglet pour se connecter, comme expliqué ici :

@Dev-in-the-BM

Quand quelqu’un essaie de répondre, il est redirigé vers une nouvelle page pour se connecter, même s’il est déjà connecté.

Se connecter de l’autre côté ne sert à rien.

[Dev-in-the-BM]

@Falco

Ouvrez la console Rails et définissez le cookie du site sur « none ».

J’y avais pensé, mais c’est très peu sécurisé, ce n’est clairement pas une bonne idée.

[NateDhaliwal]

@Dev-in-the-BM

J’y avais pensé, mais c’est très peu sécurisé, ce n’est évidemment pas une bonne idée.

Petite précision : la personne qui a suggéré cela est celle qui a aidé à créer cette fonctionnalité .

[RGJ (Richard - Communiteq)]

@Dev-in-the-BM

J’y avais pensé, mais c’est très peu sécurisé, ce n’est évidemment pas une bonne idée.

L’intégration interdomaine n’est pas toujours la meilleure solution non plus, mais bon.