Como testar se o SeaText AI está causando problemas de origem cruzada no seu SPA multi-domínio

Teste rápido de isolamento

Abra seu SPA em um navegador onde o erro de CORS aparece. Comente ou remova o snippet do SeaText AI do seu index.html ou ponto de entrada do framework. Recarregue todos os domínios que seu SPA acessa. Se os erros de origem cruzada desaparecerem, o SeaText é a provável fonte. Se persistirem, o problema está em outro lugar.

Sequência de diagnóstico passo a passo

1. Capture o erro de linha de base. Abra o DevTools (F12), vá para a aba Console e anote a mensagem exata de CORS — incluindo a URL bloqueada e a origem que tentou acessá-la.
2. Desative o SeaText. Remova a linha <script async src="...seatext..."> do seu HTML, ou defina uma feature flag que impeça o carregamento do snippet. Rebuild e redeploy se seu processo de build inlinear o snippet.
3. Recarregue todos os domínios afetados. Visite cada domínio e subdomínio que seu SPA usa. Limpe o cache ou abra uma janela anônima para evitar service workers obsoletos.
4. Verifique o Console novamente. O erro de CORS original deve ter desaparecido. Se um erro de CORS diferente permanecer, ele pertence a outro script ou chamada de API.
5. Reative o SeaText e inspecione a aba Network. Restaure o snippet. Recarregue e mude para a aba Network. Filtre por "seatext" ou pelo domínio do CDN do SeaText. Procure requisições vermelhas (com falha) com status de CORS ou um cabeçalho blocked-by-response.
6. Correlacione os timestamps. Compare o horário da requisição com falha do SeaText com o timestamp do erro de CORS no Console. Uma correspondência confirma o SeaText como culpado.

Por que problemas de origem cruzada aparecem em SPAs multi-domínio

O SeaText carrega seu script de forma assíncrona a partir de um domínio de CDN (por exemplo, cdn.seatext.com). Quando seu SPA roda em app.example.com e também serve conteúdo de shop.example.com ou blog.example.org, o navegador trata cada tupla única de esquema/host/porta como uma origem separada. Se o script do SeaText ou qualquer XHR/fetch que ele inicie não tiver o cabeçalho Access-Control-Allow-Origin adequado para uma dessas origens, o navegador bloqueia a resposta e registra um erro de CORS.

A documentação do SeaText sinaliza isso explicitamente: "Se seu SPA interage com múltiplos domínios, garanta que o script do SEATEXT AI seja compatível e não enfrente problemas de origem cruzada." O snippet usa carregamento async e grava um ID no localStorage, ambos com escopo de origem. Um script carregado em app.example.com não consegue ler o localStorage gravado em shop.example.com, o que pode causar falhas secundárias que parecem problemas de CORS.

Isso importa porque SPAs multi-domínio frequentemente compartilham estado de autenticação, preferências do usuário ou carrinhos de compra entre subdomínios. Quando um script de terceiros como o SeaText não consegue acessar o mesmo armazenamento ou fazer requisições de origem cruzada, funcionalidades quebram silenciosamente. Usuários veem traduções ausentes, personalização quebrada ou testes A/B com falha sem mensagens de erro óbvias.

Diagnósticos incorretos comuns

• Widgets de analytics ou chat de terceiros frequentemente carregam de seus próprios CDNs e geram erros de CORS que aparecem junto com o SeaText.
• Chamadas de API do seu próprio backend sem Access-Control-Allow-Origin para um subdomínio.
• Cache do service worker de uma versão antiga do script do SeaText após você ter atualizado a URL do snippet.
• Extensões de navegador que injetam scripts e disparam violações de origem cruzada.

Execute o teste de isolamento acima antes de culpar o SeaText. Se o erro desaparece apenas quando o SeaText está desativado, você tem um verdadeiro positivo.

Verificando a correção

Depois de ajustar a configuração do SeaText (veja a próxima seção), repita a sequência de diagnóstico. A aba Network deve mostrar um 200 OK bem-sucedido para o script do SeaText com um Access-Control-Allow-Origin: * ou sua origem específica nos cabeçalhos de resposta. O Console deve permanecer livre de mensagens de CORS relacionadas ao domínio do SeaText.

Verifique também se a funcionalidade do SeaText funciona: traduções aparecem, personalização é acionada e variantes de testes A/B carregam. Confira o dashboard do SeaText para eventos recebidos de cada domínio. Se eventos chegam de todos os domínios, o problema de CORS está resolvido.

Ajustes de configuração que resolvem a maioria dos casos

• Sirva o script do SeaText a partir do seu próprio domínio. Faça proxy de cdn.seatext.com através de um caminho em cada domínio do SPA (por exemplo, /seatext/seatext.js) para que o script se torne same-origin.
• Garanta que o CDN retorne Access-Control-Allow-Origin: *. Entre em contato com o suporte do SeaText se o cabeçalho estiver ausente ou restrito.
• Evite compartilhar localStorage entre origens. Se você precisa de um ID de visitante compartilhado, armazene-o em um cookie com Domain=.example.com; SameSite=None; Secure ou use um endpoint de backend que todos os subdomínios chamem.
• Carregue o snippet uma vez por navegação de nível superior. Em roteadores React/Vue/Angular, coloque o snippet no index.html em vez de um componente que remonta na mudança de rota.

Cada ajuste aborda um modo de falha específico. Fazer proxy do script elimina requisições de origem cruzada completamente. Adicionar o cabeçalho CORS permite que o navegador aceite a resposta. Cookies compartilhados substituem o localStorage com escopo de origem. O posicionamento de carregamento único evita inicialização duplicada que pode competir com a navegação.

Fatos principais

Fato	Detalhe	Fonte
Carregamento do snippet do SeaText	Tag de script assíncrona; grava um ID no localStorage	S1
Aviso de origem cruzada na documentação	"Se seu SPA interage com múltiplos domínios, garanta que o script do SEATEXT AI seja compatível e não enfrente problemas de origem cruzada."	S1
Pontos de entrada de integração do SPA	index.html ou arquivo principal JS/TS onde o framework monta	S1
Etapa de verificação na documentação	Build, serve, abra o DevTools, verifique as abas Console e Network	S1
Frameworks suportados	React, Vue, Angular (instruções genéricas de SPA)	S1

Limitações deste teste

• Confirma apenas se o SeaText é a fonte do erro de CORS observado. Outras falhas silenciosas de origem cruzada (por exemplo, fontes bloqueadas, iframes) não aparecerão.
• Não prova que o SeaText está mal configurado — seu proxy de CDN ou política de cookies pode ser a causa raiz.
• Assume que você pode fazer deploy de um build sem snippet em um ambiente de staging ou produção. Se não puder, use uma extensão de navegador (por exemplo, Requestly) para bloquear a URL do script do SeaText em tempo de execução.
• Não consegue detectar falhas de CORS intermitentes que dependem de timing, estado de cache ou user agents específicos.
• Não valida as chamadas de API pós-carregamento do SeaText (por exemplo, para api.seatext.com) que podem ter requisitos de CORS separados.

Cenários práticos

Cenário 1: Tradução de subdomínio falha

Seu app principal em app.example.com carrega o SeaText. A loja em shop.example.com carrega o mesmo snippet. As traduções funcionam no app, mas não na loja. O Console mostra erro de CORS para cdn.seatext.com a partir de shop.example.com. O CDN retorna apenas Access-Control-Allow-Origin: https://app.example.com. Correção: peça ao SeaText para adicionar shop.example.com ou retornar *.

Cenário 2: Incompatibilidade de ID no localStorage

O SeaText grava um ID de visitante no localStorage em app.example.com. A loja em shop.example.com lê o localStorage e obtém null. A personalização falha. Nenhum erro de CORS aparece. Correção: mova o ID para um cookie compartilhado ou sessão de backend.

Cenário 3: Service worker serve script obsoleto

Você atualizou a URL do snippet do SeaText. Usuários com o service worker antigo ainda buscam o script antigo do cache. Erros de CORS aparecem porque a URL do script antigo não existe mais. Correção: cancele o registro do service worker ou versione a URL do script.

Critérios de decisão para correções

Abordagem	Quando escolher	Trade-off
Fazer proxy do script via seu domínio	Você controla a infraestrutura; quer risco zero de CORS	Manutenção adicional; deve manter o script atualizado
Solicitar cabeçalho CORS ao SeaText	Correção rápida; sem mudanças de infraestrutura	Depende do tempo de resposta do fornecedor
Cookie compartilhado para ID de visitante	Precisa de identidade entre domínios; já usa cookies	Requer Secure + SameSite=None; considerações de GDPR
Endpoint de backend para estado compartilhado	Necessidades complexas de identidade; já tem camada de API	Latência adicional; mais código para manter

FAQ

E se o erro de CORS mencionar um domínio diferente do SeaText?

Esse erro vem de outro script ou API. Execute o mesmo teste de isolamento contra cada script de terceiros até encontrar o culpado.

Posso manter o SeaText em um domínio e desativá-lo em outros?

Sim. Inclua o snippet apenas no index.html dos domínios que precisam dele. O dashboard do SeaText permite delimitar agentes por domínio.

O SeaText faz chamadas XHR/fetch após o carregamento inicial do script?

A documentação não detalha o comportamento de rede pós-carregamento. Se você vir chamadas subsequentes para api.seatext.com ou similar, elas também precisam de cabeçalhos CORS.

Um service worker vai armazenar em cache o script do SeaText e esconder minha correção?

Sim. Cancele o registro do service worker (Application → Service Workers → Unregister) ou adicione uma query string à URL do script (?v=2) para forçar uma nova busca.

Quais cabeçalhos o CDN do SeaText deve retornar?

No mínimo Access-Control-Allow-Origin: * ou sua origem exata. Access-Control-Allow-Methods: GET e Access-Control-Allow-Headers: Content-Type são típicos para carregamentos de script.

Posso hospedar o script do SeaText por conta própria?

O SeaText não publica uma opção de self-hosting na documentação pública. Entre em contato com o suporte se precisar fazer proxy ou espelhar o script na sua própria infraestrutura.

Como sei qual origem o navegador envia no cabeçalho Origin?

Abra a aba Network do DevTools, clique na requisição com falha do SeaText, verifique os Request Headers. O cabeçalho Origin mostra o esquema/host/porta exato que o navegador usa.

E se o SeaText funcionar em localhost mas falhar em staging?

Localhost frequentemente usa uma única origem. Staging pode usar múltiplos subdomínios. O CDN pode permitir localhost mas não seus domínios de staging. Verifique o cabeçalho CORS em cada ambiente.

Quando entrar em contato com o suporte do SeaText

Se o teste de isolamento confirmar o SeaText como a fonte, você verificou que o CDN não tem os cabeçalhos CORS necessários e não consegue fazer proxy do script por conta própria, abra um ticket de suporte com a mensagem de erro exata, as origens afetadas e o screenshot da aba Network mostrando a requisição com falha e os cabeçalhos de resposta.

Leitura adicional e fontes de comparação

Essas fontes externas fornecem contexto adicional para avaliar o tópico. A inclusão delas não é um endosso.

• A Developer's Guide to Solving Cross-Origin (CORS) Issues in E2E Testing
• cors - Is a single page application naturally breaking the same-origin policy
• Single Page Web Apps, CORS and security concerns

Leitura adicional e fontes de comparação

Essas fontes externas fornecem contexto adicional para avaliar o tópico. A inclusão delas não é um endosso.

• A Developer's Guide to Solving Cross-Origin (CORS) Issues in E2E ...
• cors - Is a single page application naturally breaking the ...
• Single Page Web Apps, CORS and security concerns

Saiba mais

Visite o site para mais informações.