Is using the full app embed on another domain possible?

[Dev-in-the-BM]

I’m using a Discourse forum as the comments section for my blog, which is on a separate domain.

I’m trying to use the Discourse full app embed, but users can’t login, reply, or interact at all from the embed.

When someone tries replying, it redirects them to sign in on a new page, even if they’re already logged in.

Signing in on over there doesn’t help.

It sounds like it’s a problem with cross site cookies.

Is there any way around this?

Any fix?

---

Sorry, I’m not really familiar with all these cookie stuff, so I used AI to understand what’s going on and research possible solutions.

If you don’t like AI, you can stop here.

I put what I got from them below, but this post itself, including all formatting, was written using my Natural Intelligence.

How Gemini summarized the problem.

@Gemini

The “Full App” embed fails to recognize active user sessions when the forum and the site use different domains.

This happens because the browser treats the embedded forum as a third-party tracker.

Modern browsers block third-party cookies by default to protect user privacy.

Discourse session cookies are set to SameSite=Lax.

Browsers will not send Lax cookies inside an iframe if the parent domain is different.

Because the cookies are blocked, the forum cannot see the user’s login data.

The embed defaults to “Guest” mode and triggers a new tab when the user tries to interact.

Obvious fixes like whitelisting the host in Discourse settings do not work.

Whitelisting only tells Discourse to allow the connection; it cannot override the browser’s security rules.

Refreshing the page or re-logging in a new tab also fails because the browser-level block remains active for the iframe.

The embed essentially stays trapped in a cookie-less sandbox.

It sounds like there are right ways to do this, but Discourse would have to implement them.

@Google Search AI Mode

Yes, there are officially supported, secure methods, but the “old way” (just setting a cookie) is dead. ^[1]

To persist a login in an iframe today, you must use one of the following three “official” browser standards. Which one you choose depends entirely on who needs to see the login session.

1. The “Private Jar” Method: CHIPS

Best for: Chat widgets, embedded maps, or payment forms that need to stay logged in only on this specific parent site.

• How it works: You set a cookie with the Partitioned attribute.

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

• The Result: The browser creates a unique “cookie jar” for your iframe that is keyed to (Your Domain + Parent Page Domain).

• Pros: It works automatically without asking the user for permission.

• Cons: The session is not shared. If the user visits your site directly in a new tab, they will not be logged in there. They are only logged in within that specific embed context. ^[2]

2. The “Shared Session” Method: Storage Access API (SAA)

Best for: When you need the iframe to see the same login session as the user’s main tab (e.g., a “Comment as [User]” widget). ^[3]

• How it works: The iframe cannot read its own cookies initially. It must call a specific JavaScript API to request access:

document.requestStorageAccess().then(() => {
  // Now you can read your cross-site cookies!
});

• The Catch: This requires a user gesture (like a click). You typically have to render a “Click to connect” button first. Once clicked, the browser may prompt the user (“Allow [iframe] to use cookies?”).
• Pros: Grants access to your “real” global cookies.
• Cons: High friction; requires user interaction/popups. ^[4][5]

3. The “Token Handoff” Method (Most Common)

Best for: SaaS apps embedding their own tools into customer dashboards.

• How it works: You don’t rely on iframe cookies at all.

  1. Parent Page handles the login (or already has the token).
  2. Parent passes the auth token (JWT) to the iframe via postMessage.
  3. Iframe catches the token and stores it in memory (or sessionStorage) to attach to API requests.

• Pros: Zero reliance on browser cookie policies; completely cross-browser compatible.

• Cons: Requires code changes on both the parent page and the iframe site. ^[6]

Summary Recommendation

If you need… [4:1][7][8]	Use…
Isolated login (Widget state doesn’t need to match main site)	CHIPS (Partitioned Cookies)
Global login (User is already logged in to your site elsewhere)	Storage Access API
Control (You own both the parent site and the iframe)	Token Handoff (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

I’m trying to use the Discourse full app embed, but users can’t login, reply, or interact at all from the embed.

When someone tries replying, it redirects them to sign in on a new page, even if they’re already logged in.

is your Discourse up to date? make sure you update to latest version. i have no problems replying when logged in to the correct forum.

replying as anon opens a new tab to log in as explained here:

@Falco

@Heliosurge

If a visitor has no account will it prompt them to create one?

Yes, it opens a new tab for login.

[Falco]

Enter the rails console and set the same site cookie to none.

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

[Dev-in-the-BM]

@Lilly

is your Discourse up to date?

Yes.

@Lilly

i have no problems replying when logged in to the correct forum.

Within the same domain, or across different sites?

@Lilly

replying as anon opens a new tab to log in as explained here:

@Dev-in-the-BM

When someone tries replying, it redirects them to sign in on a new page, even if they’re already logged in.

Signing in on over there doesn’t help.

[Dev-in-the-BM]

@Falco

Enter the rails console and set the same site cookie to none.

I thought of that, but that’s very insecure, obviously not a good idea.

[NateDhaliwal]

@Dev-in-the-BM

I thought of that, but that’s very insecure, obviously not a good idea.

Just a note that the person who suggested that was the one who helped make the feature .

[RGJ (Richard - Communiteq)]

@Dev-in-the-BM

I thought of that, but that’s very insecure, obviously not a good idea.

Cross domain embedding is not always the best idea either, but hey.