別のドメインでフルアプリ埋め込みを使用することは可能ですか？

[Dev-in-the-BM]

私は、別ドメイン上のブログのコメント欄として Discourse フォーラムを利用しています。

Discourse のフルアプリ埋め込みを使用しようとしていますが、埋め込み内ではユーザーがログイン、返信、または一切のインタラクションを行えません。

返信を試みると、ユーザーがすでにログインしていても、新しいページでサインインするようにリダイレクトされてしまいます。

そちら側でサインインしても解決しません。

これはクロスサイトクッキーに関する問題のようです。

回避策はありますか？

解決策はありますか？

---

申し訳ありませんが、私はこれらのクッキーに関する仕組みに詳しくないため、何が起きているのかを理解し、考えられる解決策を調査するために AI を使用しました。

AI が好きでない場合は、ここで読むのをやめてください。

以下に AI から得た情報を記載しますが、この投稿自体（すべての書式設定を含む）は、私の「自然知能」を使用して作成しました。

Gemini が問題を要約した内容

@Gemini

「フルアプリ」埋め込みは、フォーラムとサイトが異なるドメインを使用している場合、アクティブなユーザーセッションを認識できません。

これは、ブラウザが埋め込まれたフォーラムをサードパーティのトラッカーとして扱うために発生します。

現代のブラウザは、ユーザーのプライバシーを保護するために、デフォルトでサードパーティのクッキーをブロックします。

Discourse のセッションクッキーは SameSite=Lax に設定されています。

ブラウザは、親ドメインが異なる場合、iframe 内で Lax クッキーを送信しません。

クッキーがブロックされるため、フォーラムはユーザーのログインデータを認識できません。

埋め込みはデフォルトで「ゲスト」モードになり、ユーザーがインタラクションを試みると新しいタブがトリガーされます。

Discourse の設定でホストをホワイトリストに追加するなどの明らかな解決策は機能しません。

ホワイトリストへの追加は、Discourse に接続を許可するよう指示するだけで、ブラウザのセキュリティルールを上書きすることはできません。

ページをリフレッシュしたり、新しいタブで再ログインしたりしても失敗します。これは、ブラウザレベルのブロックが iframe に対して引き続き有効なためです。

埋め込みは、事実上、クッキーのないサンドボックスに閉じ込められた状態になります。

これを行う正しい方法があるようですが、Discourse がそれらを実装する必要があります

@Google Search AI Mode

はい、公式にサポートされた安全な方法がありますが、「古い方法」（単にクッキーを設定するだけ）は廃止されました。^[1]

現在、iframe 内でログインを維持するには、以下の 3 つの「公式」ブラウザ標準のいずれかを使用する必要があります。どれを選択するかは、誰がログインセッションを確認する必要があるかに完全に依存します。

1. 「プライベートジャー」方式：CHIPS

最適ケース：チャットウィジェット、埋め込みマップ、または この特定の親サイトでのみ ログイン状態を維持する必要がある決済フォームなど。

• 仕組み：Partitioned 属性を持つクッキーを設定します。

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

• 結果：ブラウザは、(あなたのドメイン + 親ページドメイン) をキーとする、あなたの iframe のための一意の「クッキージャー」を作成します。

• 長所：ユーザーの許可を求めずに自動的に機能します。

• 短所：セッションは共有されません。ユーザーが新しいタブで直接サイトを訪問しても、そこでは ログインしていません。その特定の埋め込みコンテキスト内でのみログイン状態が維持されます。^[2]

2. 「共有セッション」方式：Storage Access API (SAA)

最適ケース：iframe がユーザーのメインタブと同じログインセッションを表示する必要がある場合（例：「[ユーザー] としてコメント」ウィジェットなど）。^[3]

• 仕組み：iframe は当初、自身のクッキーを読み取ることができません。アクセスを要求するために特定の JavaScript API を呼び出す必要があります。

document.requestStorageAccess().then(() => {
  // これでクロスサイトクッキーを読み取ることができます！
});

• 注意点：これにはユーザーのジェスチャー（クリックなど）が必要です。通常、まず「接続をクリック」ボタンをレンダリングする必要があります。クリックされると、ブラウザはユーザーにプロンプトを表示する場合があります（「[iframe] がクッキーを使用することを許可しますか？」）。
• 長所：「実際の」グローバルクッキーへのアクセスを付与します。
• 短所：摩擦が高く、ユーザーの操作/ポップアップが必要です。^[4][5]

3. 「トークンハンドオフ」方式（最も一般的）

最適ケース：SaaS アプリが顧客ダッシュボードに自社のツールを埋め込む場合。

• 仕組み：iframe クッキーには一切依存しません。

  1. 親ページがログインを処理する（またはすでにトークンを持っている）。
  2. 親ページが認証トークン（JWT）を postMessage 経由で iframe に渡す。
  3. iframe がトークンをキャッチし、メモリ（または sessionStorage）に保存して、API リクエストに添付する。

• 長所：ブラウザのクッキーポリシーに依存せず、クロスブラウザ互換性が完全に確保される。

• 短所：親ページと iframe サイトの両方でコード変更が必要。^[6]

推奨サマリー

必要なもの [4:1][7][8]	使用する方式
隔離されたログイン（ウィジェットの状態がメインサイトと一致する必要がない）	CHIPS（パーティション化されたクッキー）
グローバルログイン（ユーザーがすでに別の場所でサイトにログインしている）	Storage Access API
制御（親サイトと iframe の両方を所有している）	トークンハンドオフ（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

Discourse のフルアプリ埋め込みを使用しようとしているのですが、埋め込み部分からはユーザーがログイン、返信、または一切のやり取りができません。

返信を試みると、すでにログインしていても別ページでサインインにリダイレクトされてしまいます。

Discourse は最新バージョンになっていますか？最新バージョンに更新してください。正しいフォーラムにログインしている状態で返信する際、私は問題が発生していません。

匿名で返信すると、ここで説明されているようにログインのために新しいタブが開きます。

@Falco

@Heliosurge

訪問者にアカウントがない場合、アカウント作成を促すのでしょうか？

はい、ログインのために新しいタブが開きます。

[Falco]

Rails コンソールにアクセスし、same_site クッキーを “None” に設定します。

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

[Dev-in-the-BM]

@Lilly

Discourse は最新バージョンですか？

はい、最新です。

@Lilly

正しいフォーラムにログインしている場合は、返信に問題ありません。

同じドメイン内ですか、それとも異なるサイト間ですか？

@Lilly

匿名で返信しようとすると、こちらで説明されているようにログインするために新しいタブが開きます：

@Dev-in-the-BM

誰かが返信を試みると、すでにログインしていても、新しいページでサインインするようにリダイレクトされます。

あちらでサインインしても解決しません。

[Dev-in-the-BM]

@Falco

Rails コンソールに入って、同じサイトクッキーを none に設定してください。

それもいいと思ったんですが、それは非常にセキュリティ上問題があり、明らかに良いアイデアではありません。

[NateDhaliwal]

@Dev-in-the-BM

それ想到了けど、それは非常にセキュリティ上問題があるから、明らかに良いアイデアじゃないね。

余談だけど、その提案をした人は、実はその機能の実装を手伝った人なんだよ 。

[RGJ (Richard - Communiteq)]

@Dev-in-the-BM

それ想到了けど、それは非常に不安全で、明らかに良いアイデアではないね。

ドメインを跨いだ埋め込みも常に最善策とは限らないけど、まあね。