# Возможно ли использовать полный виджет приложения на другом домене?

**URL:** https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180
**Category:** Support
**Tags:** embedding
**Created:** [04.Май.2026 23:12:38 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:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![Dev-in-the-BM](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/dev-in-the-bm/32/524987_2.png) [@Dev-in-the-BM](https://meta.discourse.org/u/Dev-in-the-BM)
#### Post date: [04.Май.2026 23:12:38 UTC](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180/1 "2026-05-04T23:12:38Z")

</div>

Я использую форум Discourse в качестве раздела комментариев для своего блога, который находится на другом домене.

Я пытаюсь внедрить полное приложение Discourse, но пользователи не могут войти в систему, отвечать или взаимодействовать каким-либо образом из этого внедрения.

Когда кто-то пытается ответить, его перенаправляет на страницу входа, даже если он уже вошел в систему.

Вход в систему на стороне форума не помогает.

Похоже, это проблема с межсайтовыми cookie-файлами.

Есть ли какой-либо обходной путь?

Есть ли решение?

* * *

Извините, я не очень хорошо разбираюсь во всех этих вопросах, связанных с cookie-файлами, поэтому использовал ИИ, чтобы понять, что происходит, и найти возможные решения.

Если вы не любите ИИ, можете остановиться здесь.

Ниже я привел то, что получил от него, но сам этот пост, включая все форматирование, был написан с помощью моего естественного интеллекта.

> **Как Gemini обобщил проблему.**
>
> > [@Gemini](#):
> >
> > Внедрение «Полного приложения» не распознает активные сессии пользователей, когда форум и сайт используют разные домены.
> > 
> > Это происходит потому, что браузер воспринимает встроенный форум как сторонний трекер.
> > 
> > Современные браузеры по умолчанию блокируют сторонние cookie-файлы для защиты конфиденциальности пользователей.
> > 
> > Сессионные cookie-файлы Discourse настроены как `SameSite=Lax`.
> > 
> > Браузеры не отправляют cookie-файлы `Lax` внутри iframe, если родительский домен отличается.
> > 
> > Поскольку cookie-файлы блокируются, форум не может увидеть данные входа пользователя.
> > 
> > Внедрение по умолчанию переходит в режим «Гость» и открывает новую вкладку, когда пользователь пытается взаимодействовать.
> > 
> > Очевидные решения, такие как добавление хоста в белый список в настройках Discourse, не работают.
> > 
> > Добавление в белый список только сообщает Discourse разрешить соединение; оно не может переопределить правила безопасности браузера.
> > 
> > Обновление страницы или повторный вход в новой вкладке также не помогает, поскольку блокировка на уровне браузера остается активной для iframe.
> > 
> > Внедрение по сути остается запертым в песочнице без cookie-файлов.

  

> **Похоже, есть правильные способы сделать это, но Discourse должен их реализовать.**
>
> > [@Google Search AI Mode](#):
> >
> > Да, существуют официально поддерживаемые безопасные методы, но «старый способ» (просто установка cookie) устарел. \[1\]
> > 
> > Чтобы сохранить вход в системе в iframe сегодня, необходимо использовать один из следующих трех «официальных» стандартов браузера. Выбор зависит от того, кто должен видеть сессию входа.
> > 
> > ## 1. Метод «Частного хранилища»: CHIPS
> > 
> > Лучше всего подходит для: виджетов чата, встроенных карт или платежных форм, которым нужно оставаться в системе _только_ на этом конкретном родительском сайте.
> > 
> > - Как это работает: Вы устанавливаете cookie-файл с атрибутом `Partitioned`.
> > 
> > - Результат: Браузер создает уникальное «хранилище cookie» для вашего iframe, привязанное к (Ваш домен + Домен родительской страницы).
> > 
> > - Плюсы: Работает автоматически без запроса разрешения у пользователя.
> > 
> > - Минусы: Сессия не общая. Если пользователь посетит ваш сайт напрямую в новой вкладке, он _не_ будет там в системе. Он будет в системе только в контексте этого конкретного внедрения. \[2\]
> > 
> > ## 2. Метод «Общей сессии»: Storage Access API (SAA)
> > 
> > Лучше всего подходит для: случаев, когда iframe должен видеть ту же сессию входа, что и основная вкладка пользователя (например, виджет «Комментировать как [Пользователь]»). \[3\]
> > 
> > - Как это работает: Изначально iframe не может читать свои собственные cookie-файлы. Он должен вызвать специальный JavaScript API для запроса доступа:
> > 
> > ```plaintext
> > document.requestStorageAccess().then(() => {
> > // Теперь вы можете читать свои межсайтовые cookie-файлы!
> > });
> > 
> > ```
> > 
> > - Подвох: Это требует действия пользователя (например, клика). Обычно сначала нужно отобразить кнопку «Нажмите для подключения». После клика браузер может запросить разрешение у пользователя («Разрешить [iframe] использовать cookie?»).
> > - Плюсы: Предоставляет доступ к вашим «настоящим» глобальным cookie-файлам.
> > - Минусы: Высокий уровень трения; требует взаимодействия пользователя/всплывающих окон. \[4\]\[5\]
> > 
> > ## 3. Метод «Передачи токена» (Наиболее распространенный)
> > 
> > Лучше всего подходит для: SaaS-приложений, внедряющих свои собственные инструменты в панели управления клиентов.
> > 
> > - Как это работает: Вы вообще не полагаетесь на cookie-файлы iframe.
> > 
> > - Плюсы: Полное отсутствие зависимости от политик cookie-файлов браузера; полностью совместим со всеми браузерами.
> > 
> > - Минусы: Требует изменений кода как на родительской странице, так и на сайте iframe. \[6\]
> > 
> > ## Резюме и рекомендации
> > 
> > | Если вам нужно… \[4:1\]\[7\]\[8\] | Используйте… |
> > | --- | --- |
> > | Изолированный вход (Состояние виджета не должно совпадать с основным сайтом) | CHIPS (Разделенные cookie-файлы) |
> > | Глобальный вход (Пользователь уже вошел в систему на вашем сайте в другом месте) | Storage Access API |
> > | Контроль (Вы владеете как родительским сайтом, так и iframe) | Передача токена (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)

---

_[View the full topic](https://meta.discourse.org/t/is-using-the-full-app-embed-on-another-domain-possible/402180)._