# Is using the full app embed on another domain possible?
**URL:** https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180
**Category:** Support
**Tags:** embedding
**Created:** [May 4, 2026, 11:12pm UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180 "2026-05-04T23:12:38Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Dev-in-the-BM](https://meta.discourse.org/u/Dev-in-the-BM)
#### Post date: [May 4, 2026, 11:12pm UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/1 "2026-05-04T23:12:38Z")
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.
> >
> > - 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:
> >
> > ```plaintext
> > 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.
> >
> > - 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](https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API)
2. [https://help.boldbi.com](https://help.boldbi.com/security-configuration/enable-chips-for-iframe-embedding/)
3. [https://developers.google.com](https://developers.google.com/identity/gsi/web/amp/intermediate-iframe)
4. [https://privacysandbox.google.com](https://privacysandbox.google.com/cookies/storage-access-api)
5. [https://learn.microsoft.com](https://learn.microsoft.com/en-us/entra/msal/javascript/browser/iframe-usage#:~:text=Azure%20AD%20B2C%20offers%20an%20embedded%20sign%2Din,not%20recommended%2C%20due%20to%20the%20above%20restriction.)
6. [https://www.blackduck.com](https://www.blackduck.com/blog/protect-your-website-with-iframes.html)
7. [https://developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using)
8. [https://stackoverflow.com](https://stackoverflow.com/questions/12357123/log-in-to-a-remote-site-through-an-iframe)
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [May 5, 2026, 12:01am UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/2 "2026-05-05T00:01:32Z")
> [@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:
> [@Embed Discourse as a full comment system on your site](https://meta.discourse.org/t/embed-discourse-as-a-full-comment-system-on-your-site/399743/7):
>
> > [@Embed Discourse as a full comment system on your site](https://meta.discourse.org/t/embed-discourse-as-a-full-comment-system-on-your-site/399743/6):
> >
> > If a visitor has no account will it prompt them to create one?
>
> Yes, it opens a new tab for login.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [May 5, 2026, 12:35am UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/3 "2026-05-05T00:35:34Z")
Enter the rails console and set the same site cookie to none.
```plaintext
cd /var/discourse
./launcher enter app
rails c
SiteSetting.same_site_cookies = "None"
```
---
### Author:  [@Dev-in-the-BM](https://meta.discourse.org/u/Dev-in-the-BM)
#### Post date: [May 5, 2026, 2:01am UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/4 "2026-05-05T02:01:58Z")
> [@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.
---
### Author:  [@Dev-in-the-BM](https://meta.discourse.org/u/Dev-in-the-BM)
#### Post date: [May 5, 2026, 2:14am UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/5 "2026-05-05T02:14:36Z")
> [@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.
---
### Author:  [@NateDhaliwal](https://meta.discourse.org/u/NateDhaliwal)
#### Post date: [May 5, 2026, 2:31am UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/6 "2026-05-05T02:31:58Z")
> [@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 😉.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [May 5, 2026, 7:46am UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/7 "2026-05-05T07:46:17Z")
> [@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.