Cómo comprobar si SeaText AI está causando problemas de origen cruzado en tu SPA multidominio

Prueba de aislamiento rápida

Abre tu SPA en un navegador donde aparezca el error CORS. Comenta o elimina el fragmento de SeaText AI de tu index.html o del punto de entrada del framework. Recarga todos los dominios que toca tu SPA. Si los errores de origen cruzado desaparecen, SeaText es la fuente probable. Si persisten, el problema está en otro lugar.

Secuencia de diagnóstico paso a paso

1. Captura el error de referencia. Abre DevTools (F12), ve a la pestaña Consola y anota el mensaje CORS exacto, incluida la URL bloqueada y el origen que intentó acceder a ella.
2. Desactiva SeaText. Elimina la línea <script async src="...seatext..."> de tu HTML, o establece un indicador de función que impida que se cargue el fragmento. Recompila y vuelve a desplegar si tu proceso de compilación inserta el fragmento en línea.
3. Recarga todos los dominios afectados. Visita cada dominio y subdominio que use tu SPA. Borra la caché o abre una ventana de incógnito para evitar service workers obsoletos.
4. Revisa la Consola de nuevo. El error CORS original debería haber desaparecido. Si queda un error CORS diferente, pertenece a otro script o llamada API.
5. Vuelve a habilitar SeaText e inspecciona Red. Restaura el fragmento. Recarga y cambia a la pestaña Red. Filtra por "seatext" o el dominio CDN de SeaText. Busca solicitudes en rojo (fallidas) con un estado CORS o un encabezado blocked-by-response.
6. Correlaciona las marcas de tiempo. Haz coincidir la hora de la solicitud fallida de SeaText con la marca de tiempo del error CORS en la Consola. Una coincidencia confirma que SeaText es el culpable.

Por qué aparecen problemas de origen cruzado en SPA multidominio

SeaText carga su script de forma asíncrona desde un dominio CDN (p. ej., cdn.seatext.com). Cuando tu SPA se ejecuta en app.example.com y también sirve contenido desde shop.example.com o blog.example.org, el navegador trata cada combinación única de esquema/host/puerto como un origen separado. Si el script de SeaText o cualquier XHR/fetch que inicie carece del encabezado Access-Control-Allow-Origin adecuado para uno de esos orígenes, el navegador bloquea la respuesta y registra un error CORS.

La documentación de SeaText lo advierte explícitamente: "Si tu SPA interactúa con múltiples dominios, asegúrate de que el script de SEATEXT AI sea compatible y no enfrente problemas de origen cruzado". El fragmento usa carga async y escribe un ID en localStorage, ambos limitados al origen. Un script cargado en app.example.com no puede leer el localStorage escrito en shop.example.com, lo que puede causar fallos secundarios que parecen problemas CORS.

Esto importa porque las SPA multidominio a menudo comparten estado de autenticación, preferencias de usuario o carritos de compra entre subdominios. Cuando un script de terceros como SeaText no puede acceder al mismo almacenamiento ni hacer solicitudes de origen cruzado, las funciones fallan silenciosamente. Los usuarios ven traducciones faltantes, personalización rota o pruebas A/B fallidas sin mensajes de error obvios.

Diagnósticos erróneos comunes

• Los widgets de análisis o chat de terceros a menudo se cargan desde sus propios CDN y generan errores CORS que aparecen junto a SeaText.
• Llamadas API desde tu propio backend que carecen de Access-Control-Allow-Origin para un subdominio.
• El service worker almacena en caché una versión antigua del script de SeaText después de que hayas actualizado la URL del fragmento.
• Extensiones del navegador que inyectan scripts y provocan violaciones de origen cruzado.

Ejecuta la prueba de aislamiento anterior antes de culpar a SeaText. Si el error desaparece solo cuando SeaText está desactivado, tienes un verdadero positivo.

Verificación de la solución

Después de ajustar la configuración de SeaText (consulta la siguiente sección), repite la secuencia de diagnóstico. La pestaña Red debería mostrar un 200 OK exitoso para el script de SeaText con un Access-Control-Allow-Origin: * o tu origen específico en los encabezados de respuesta. La Consola debería permanecer libre de mensajes CORS relacionados con el dominio de SeaText.

También verifica que la funcionalidad de SeaText funciona: aparecen las traducciones, se activa la personalización y se cargan las variantes de pruebas A/B. Revisa el panel de SeaText para ver eventos entrantes de cada dominio. Si llegan eventos de todos los dominios, el problema CORS está resuelto.

Ajustes de configuración que resuelven la mayoría de los casos

• Sirve el script de SeaText desde tu propio dominio. Haz proxy de cdn.seatext.com a través de una ruta en cada dominio de la SPA (p. ej., /seatext/seatext.js) para que el script sea del mismo origen.
• Asegúrate de que el CDN devuelva Access-Control-Allow-Origin: *. Contacta con el soporte de SeaText si el encabezado falta o está restringido.
• Evita compartir localStorage entre orígenes. Si necesitas un ID de visitante compartido, guárdalo en una cookie con Domain=.example.com; SameSite=None; Secure o usa un endpoint de backend que llamen todos los subdominios.
• Carga el fragmento una vez por navegación de nivel superior. En los routers de React/Vue/Angular, coloca el fragmento en index.html en lugar de un componente que se vuelve a montar al cambiar de ruta.

Cada ajuste aborda un modo de fallo específico. Hacer proxy del script elimina por completo las solicitudes de origen cruzado. Añadir el encabezado CORS permite que el navegador acepte la respuesta. Las cookies compartidas reemplazan el localStorage limitado al origen. La colocación de carga única evita la inicialización duplicada que puede competir con la navegación.

Datos clave

Dato	Detalle	Fuente
Carga del fragmento de SeaText	Etiqueta de script asíncrona; escribe un ID en localStorage	S1
Advertencia de origen cruzado en la documentación	"Si tu SPA interactúa con múltiples dominios, asegúrate de que el script de SEATEXT AI sea compatible y no enfrente problemas de origen cruzado".	S1
Puntos de entrada de integración de SPA	index.html o archivo JS/TS principal donde se monta el framework	S1
Paso de verificación en la documentación	Compilar, servir, abrir DevTools, revisar las pestañas Consola y Red	S1
Frameworks compatibles	React, Vue, Angular (instrucciones genéricas para SPA)	S1

Limitaciones de esta prueba

• Solo confirma si SeaText es la fuente del error CORS observado. Otros fallos silenciosos de origen cruzado (p. ej., fuentes bloqueadas, iframes) no aparecerán.
• No demuestra que SeaText esté mal configurado; tu proxy CDN o política de cookies puede ser la causa raíz.
• Asume que puedes desplegar una compilación sin el fragmento en un entorno de staging o producción. Si no puedes, usa una extensión del navegador (p. ej., Requestly) para bloquear la URL del script de SeaText en tiempo de ejecución.
• No puede detectar fallos CORS intermitentes que dependen del tiempo, el estado de la caché o agentes de usuario específicos.
• No valida las llamadas API posteriores a la carga de SeaText (p. ej., a api.seatext.com) que pueden tener requisitos CORS separados.

Escenarios prácticos

Escenario 1: Falla la traducción en un subdominio

Tu aplicación principal en app.example.com carga SeaText. La tienda en shop.example.com carga el mismo fragmento. Las traducciones funcionan en la aplicación pero no en la tienda. La Consola muestra un error CORS para cdn.seatext.com desde shop.example.com. El CDN devuelve solo Access-Control-Allow-Origin: https://app.example.com. Solución: pide a SeaText que añada shop.example.com o que devuelva *.

Escenario 2: Discrepancia de ID en localStorage

SeaText escribe un ID de visitante en localStorage en app.example.com. La tienda en shop.example.com lee localStorage y obtiene null. La personalización falla. No aparece ningún error CORS. Solución: mueve el ID a una cookie compartida o a una sesión de backend.

Escenario 3: El service worker sirve un script obsoleto

Actualizaste la URL del fragmento de SeaText. Los usuarios con el service worker antiguo siguen obteniendo el script antiguo de la caché. Aparecen errores CORS porque la URL del script antiguo ya no existe. Solución: desregistra el service worker o versiona la URL del script.

Criterios de decisión para las soluciones

Enfoque	Cuándo elegirlo	Compensación
Hacer proxy del script a través de tu dominio	Controlas la infraestructura; quieres riesgo CORS cero	Mantenimiento añadido; debes mantener el script actualizado
Solicitar encabezado CORS a SeaText	Solución rápida; sin cambios de infraestructura	Depende del tiempo de respuesta del proveedor
Cookie compartida para el ID de visitante	Necesitas identidad entre dominios; ya usas cookies	Requiere Secure + SameSite=None; consideraciones GDPR
Endpoint de backend para estado compartido	Necesidades de identidad complejas; ya tienes capa API	Latencia añadida; más código que mantener

Preguntas frecuentes

¿Qué pasa si el error CORS menciona un dominio diferente a SeaText?

Ese error proviene de otro script o API. Ejecuta la misma prueba de aislamiento contra cada script de terceros hasta encontrar al culpable.

¿Puedo mantener SeaText en un dominio y desactivarlo en otros?

Sí. Incluye el fragmento solo en el index.html de los dominios que lo necesiten. El panel de SeaText te permite limitar los agentes por dominio.

¿SeaText hace llamadas XHR/fetch después de la carga inicial del script?

La documentación no detalla el comportamiento de red posterior a la carga. Si ves llamadas posteriores a api.seatext.com o similares, esas también necesitan encabezados CORS.

¿Un service worker almacenará en caché el script de SeaText y ocultará mi solución?

Sí. Desregistra el service worker (Application → Service Workers → Unregister) o incrementa la URL del script con una cadena de consulta (?v=2) para forzar una obtención nueva.

¿Qué encabezados debería devolver el CDN de SeaText?

Como mínimo Access-Control-Allow-Origin: * o tu origen exacto. Access-Control-Allow-Methods: GET y Access-Control-Allow-Headers: Content-Type son típicos para cargas de scripts.

¿Puedo autoalojar el script de SeaText?

SeaText no publica una opción de autoalojamiento en la documentación pública. Contacta con soporte si necesitas hacer proxy o replicar el script en tu propia infraestructura.

¿Cómo sé qué origen envía el navegador en el encabezado Origin?

Abre la pestaña Red de DevTools, haz clic en la solicitud fallida de SeaText, revisa los Encabezados de solicitud. El encabezado Origin muestra el esquema/host/puerto exacto que usa el navegador.

¿Qué pasa si SeaText funciona en localhost pero falla en staging?

Localhost a menudo usa un único origen. Staging puede usar múltiples subdominios. El CDN puede permitir localhost pero no tus dominios de staging. Revisa el encabezado CORS en cada entorno.

Cuándo contactar con el soporte de SeaText

Si la prueba de aislamiento confirma que SeaText es la fuente, has verificado que el CDN carece de los encabezados CORS necesarios y no puedes hacer proxy del script tú mismo, abre un ticket de soporte con el mensaje de error exacto, los orígenes afectados y la captura de pantalla de la pestaña Red que muestre la solicitud fallida y los encabezados de respuesta.

Lecturas adicionales y fuentes de comparación

Estas fuentes externas proporcionan contexto adicional para evaluar el tema. Su inclusión no constituye un respaldo.

• 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

Lecturas adicionales y fuentes de comparación

Estas fuentes externas proporcionan contexto adicional para evaluar el tema. Su inclusión no constituye un respaldo.

• 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

Más información

Visita el sitio web para obtener más información.