Estou usando um fórum Discourse como seção de comentários para meu blog, que está em um domínio separado.
Estou tentando usar o embed do aplicativo completo do Discourse, mas os usuários não conseguem fazer login, responder ou interagir de forma alguma no embed.
Quando alguém tenta responder, é redirecionado para fazer login em uma nova página, mesmo que já esteja logado.
Fazer login lá não ajuda.
Parece ser um problema com cookies de sites cruzados.
Existe alguma solução?
Alguma correção?
Desculpe, não estou muito familiarizado com tudo isso de cookies, então usei IA para entender o que está acontecendo e pesquisar possíveis soluções.
Se você não gosta de IA, pode parar por aqui.
Abaixo, coloquei o que obtive delas, mas este post em si, incluindo toda a formatação, foi escrito usando minha Inteligência Natural.
Como o Gemini resumiu o problema.
Gemini:
O embed “Full App” não reconhece sessões de usuário ativas quando o fórum e o site usam domínios diferentes.
Isso ocorre porque o navegador trata o fórum incorporado como um rastreador de terceiros.
Navegadores modernos bloqueiam cookies de terceiros por padrão para proteger a privacidade do usuário.
Os cookies de sessão do Discourse são configurados como SameSite=Lax.
Os navegadores não enviam cookies Lax dentro de um iframe se o domínio pai for diferente.
Como os cookies são bloqueados, o fórum não consegue ver os dados de login do usuário.
O embed volta ao modo “Convidado” e abre uma nova aba quando o usuário tenta interagir.
Correções óbvias, como adicionar o host à lista de permissões nas configurações do Discourse, não funcionam.
A lista de permissões apenas diz ao Discourse para permitir a conexão; ela não pode substituir as regras de segurança do navegador.
Atualizar a página ou fazer login novamente em uma nova aba também falha, pois o bloqueio no nível do navegador permanece ativo para o iframe.
O embed fica essencialmente preso em um sandbox sem cookies.
Parece que existem maneiras corretas de fazer isso, mas o Discourse precisaria implementá-las.
Sim, existem métodos oficialmente suportados e seguros, mas a “velha maneira” (apenas definir um cookie) está obsoleta.
Para manter um login em um iframe hoje, você deve usar uma das seguintes três “normas oficiais” de navegador. A escolha depende inteiramente de quem precisa ver a sessão de login.
1. O Método do “Pote Privado”: CHIPS
Melhor para: Widgets de chat, mapas incorporados ou formulários de pagamento que precisam permanecer logados apenas neste site pai específico.
Como funciona: Você define um cookie com o atributo Partitioned.
Set-Cookie: session_id=xyz; Secure; SameSite=None; Partitioned;
O Resultado: O navegador cria um “pote de cookies” exclusivo para seu iframe, vinculado a (Seu Domínio + Domínio da Página Pai).
Prós: Funciona automaticamente sem pedir permissão ao usuário.
Contras: A sessão não é compartilhada. Se o usuário visitar seu site diretamente em uma nova aba, não estará logado lá. Ele estará logado apenas dentro desse contexto específico de embed.
2. O Método de “Sessão Compartilhada”: Storage Access API (SAA)
Melhor para: Quando você precisa que o iframe veja a mesma sessão de login que a aba principal do usuário (por exemplo, um widget “Comentar como [Usuário]”).
Como funciona: O iframe não consegue ler seus próprios cookies inicialmente. Ele deve chamar uma API JavaScript específica para solicitar acesso:
document.requestStorageAccess().then(() => {
// Agora você pode ler seus cookies de sites cruzados!
});
O Problema: Isso requer uma ação do usuário (como um clique). Geralmente, você precisa renderizar primeiro um botão “Clique para conectar”. Após o clique, o navegador pode solicitar ao usuário (“Permitir que [iframe] use cookies?”).
Prós: Concede acesso aos seus cookies globais “reais”.
Contras: Alta fricção; requer interação do usuário/pop-ups.
3. O Método de “Transferência de Token” (Mais Comum)
Melhor para: Aplicações SaaS que incorporam suas próprias ferramentas nos painéis de controle dos clientes.
Como funciona: Você não depende de cookies de iframe.
A página pai gerencia o login (ou já possui o token).
A página pai passa o token de autenticação (JWT) para o iframe via postMessage.
O iframe captura o token e o armazena na memória (ou sessionStorage) para anexar às solicitações de API.
Prós: Zero dependência das políticas de cookies do navegador; totalmente compatível entre navegadores.
Contras: Requer alterações de código tanto na página pai quanto no site do iframe.
Recomendação Resumida
Se você precisa…
Use…
Login isolado (O estado do widget não precisa corresponder ao site principal)
CHIPS (Cookies Particionados)
Login global (O usuário já está logado no seu site em outro lugar)
Storage Access API
Controle (Você é dono tanto do site pai quanto do iframe)
Transferência de Token (postMessage)
Lilly
Maio 5, 2026, 12:01am
2
Dev-in-the-BM:
Estou tentando usar o aplicativo completo do Discourse incorporado, mas os usuários não conseguem fazer login, responder ou interagir de forma alguma a partir da incorporação.
Quando alguém tenta responder, é redirecionado para fazer login em uma nova página, mesmo que já esteja logado.
Seu Discourse está atualizado? Certifique-se de atualizar para a versão mais recente. Eu não tenho problemas para responder quando estou logado no fórum correto.
Responder como anônimo abre uma nova aba para fazer login, conforme explicado aqui:
Falco
Maio 5, 2026, 12:35am
3
Acesse o console do Rails e defina o mesmo cookie do site como None.
cd /var/discourse
./launcher enter app
rails c
SiteSetting.same_site_cookies = "None"
Sim.
Dentro do mesmo domínio ou entre sites diferentes?
Dev-in-the-BM:
Quando alguém tenta responder, ele é redirecionado para fazer login em uma nova página, mesmo que já esteja logado.
Fazer login lá não ajuda.
Pensei nisso, mas isso é muito inseguro, obviamente não é uma boa ideia.
Apenas uma observação: a pessoa que sugeriu isso foi quem ajudou a criar o recurso
RGJ
Maio 5, 2026, 7:46am
7
Incorporação entre domínios também nem sempre é a melhor ideia, mas enfim.
.