Puede utilizar este artículo para proteger las URL externas que utilizan sus extensiones de «custo-manifest». Verá cómo declarar dominios de confianza, configurar CORS o el acceso a la red local cuando sea necesario, y diagnosticar las solicitudes bloqueadas.
Descripción general
Las extensiones de Custo-manifest pueden acceder a direcciones URL externas: llamadas a la API REST, aplicaciones web integradas en un marco de Rainbow o carga de contenido dinámico. Para controlar a qué servidores de terceros se puede acceder, Rainbow aplica una lista de dominios de confianza configurada en la consola de administración de Rainbow.
Cualquier dominio que no figure en esta lista queda bloqueado. Dependiendo del tipo de extensión de que se trate, el bloqueo se manifiesta de forma diferente; por ello, es Essential comprender este mecanismo antes de implementar un manifiesto.
Configuración de dominios de confianza
La lista se gestiona en la consola de administración de Rainbow:
Empresa → Información → Personalización → Dominios de manifiestos personalizados
|
|
Consola de Rainbow — Personalización → pestaña «Dominios de manifiestos personalizados»
Añada una entrada por cada origen que desee permitir. Cada entrada debe seguir este formato:
<protocolo>://<dominio>[:<puerto>]| Parte | Reglas |
| protocolo | https o http — obligatorio |
| dominio | Nombre de host exacto o comodín (*.example.com) |
| puerto | Opcional — omítalo para los puertos estándar (443 / 80) |
| Barra al final / | No está permitido: la entrada no coincidirá |
Ejemplos válidos
| Entrada | Coincide con |
| https://crm.example.com | https://crm.example.com/any/path |
| https://crm.example.com:8443 | Puerto no estándar |
| https://*.example.com | Todos los subdominios |
| http://192.168.1.100:3300 | Servidor local en una red privada |
Ejemplos no válidos
| Entrada | Problema |
| crm.example.com | Falta el protocolo |
| https://crm.example.com/ | Barra al final: rechazado |
| https://crm.example.com/api | Ruta no permitida — declare únicamente el origen |
Ámbito del dominio de confianza
La comprobación del dominio de confianza se aplica de forma coherente a las URL utilizadas por Rainbow Extensions en la web y en el escritorio.
| Campo del manifiesto o uso | Repercusión del dominio de confianza |
|---|---|
command.url |
Se comprueba en llamadas REST, navegación web y casos de uso de archivos o navegación que hagan referencia a una URL. |
on-main-window-actions |
La URL de la aplicación incrustada debe ser de confianza, salvo que se utilice Popup: true. |
adaptiveCardSubmitUrl |
El punto final POST utilizado por Action.Submit debe ser de confianza. |
urlConfig |
Las URL de configuración utilizadas por los widgets o las aplicaciones integradas deben ser de confianza. |
Repercusión en las llamadas a la API REST
Las extensiones que invocan una API REST (commandType: «rest») pasan por el navegador. Se aplican dos capas de seguridad independientes:
Comprobación de dominio de confianza (por parte de Rainbow)
Si el origen del servidor REST no está declarado en la consola de Rainbow, Rainbow muestra una advertencia al cargar el manifiesto. Si se ignora la advertencia, la llamada fallará de forma silenciosa en tiempo de ejecución; no se mostrará ningún mensaje de error dentro de Rainbow.
Solución: declare el origen en Empresa → Personalización → Dominios de manifiestos personalizados.
CORS (lado del servidor REST)
Aunque Rainbow considere de confianza el dominio, el navegador también aplica las restricciones CORS. El servidor REST debe devolver los siguientes encabezados en sus respuestas:
Access-Control-Allow-Origin: https://web.openrainbow.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, AuthorizationSi no necesita restringir el acceso a un origen específico, puede utilizar el comodín:
Access-Control-Allow-Origin: *Si el servidor no devuelve estos encabezados, el navegador bloquea la llamada sin mostrar ningún mensaje en Rainbow. Si usted controla el servidor, añada los encabezados CORS. De lo contrario, solicite al dueño del servidor que actualice su configuración.
Acceso a la red local (LNA)
Si el servidor REST se ejecuta en una red local o privada (p. ej., http://192.168.1.100:3300), es posible que el navegador bloquee la llamada en virtud de la política de acceso a la red local.
Cuando el navegador detecta una solicitud dirigida a una red privada, envía primero una solicitud OPTIONS previa con:
Access-Control-Request-Private-Network: trueEl servidor debe responder añadiendo Access-Control-Allow-Private-Network: true a sus encabezados CORS:
Access-Control-Allow-Origin: https://web.openrainbow.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Private-Network: trueSi falta este encabezado, el navegador bloquea la solicitud, incluso si los encabezados CORS estándar son correctos.
Soluciones en función del contexto:
| Enfoque | Cuándo utilizarlo |
| Access-Control-Allow-Private-Network: true | Usted controla el servidor local y desea que funcione en Rainbow Web |
| Exponer a través de HTTPS + nombre de host resoluble | Implementación en producción |
| Reserve la extensión exclusivamente para Rainbow Desktop | No controla el servidor local |
Repercusión en las aplicaciones integradas
La extensión «on-main-window-actions » muestra una aplicación web de terceros dentro de la interfaz de Rainbow. Hay dos modos disponibles en función del valor de «Popup ».
Sin «Popup»: aplicación dentro del marco de Rainbow
La aplicación se carga en un <IFRAME> dentro de Rainbow. Se aplican tres capas de seguridad:
Dominios de confianza
La URL de la aplicación debe declararse en la consola de Rainbow. De lo contrario, el marco aparece, pero la página permanece en blanco o muestra un error de seguridad del navegador.
CSP / X-Frame-Options de la aplicación
La propia aplicación de destino puede negarse a ser incrustada en un iframe:
| Encabezado | Valor típico | Efecto |
| X-Frame-Options | DENY o SAMEORIGIN | Rechaza la incrustación: marco en blanco |
| Content-Security-Policy | frame-ancestors «self» o «none» | Mismo efecto, mecanismo moderno |
Cómo comprobarlo: Herramientas de desarrollador → pestaña «Red» → respuesta de la URL de la aplicación → inspeccionar encabezados.
Solución: Si tiene control sobre la aplicación, permita el origen «Rainbow» en «frame-ancestors». De lo contrario, cambie a «Popup: true» (véase el apartado 3.2).
Flujo de SSO/OAuth a través de un dominio de terceros
Si la aplicación utiliza un flujo de autenticación (SSO, OAuth 2.0, SAML…), el proveedor de identidad (IdP) suele residir en un dominio distinto al de la aplicación. Rainbow carga estas redirecciones dentro del mismo marco, por lo que deben declararse todos los dominios del flujo:
https://app.example.com ← la aplicación
https://login.microsoftonline.com ← IdP de Microsoft
https://login.example.com ← su IdP internoCon Popup: true — la aplicación se abre en una ventana dedicada
Cuando se establece Popup: true, la URL se abre en una ventana dedicada del navegador, fuera del marco de Rainbow. En este modo:
- La comprobación de dominio de confianza de Rainbow queda desactivada para esa URL.
- Las restricciones de X-Frame-Options y «frame-ancestors» de la CSP de la aplicación son irrelevantes.
- Los flujos de SSO y OAuth funcionan con normalidad en su propia ventana.
"on-main-window-actions": [{
"name": "Mi aplicación",
"icon": "${custo.path}\\app.png",
"Popup": true,
"command": {
"url": "https://app.example.com/",
"params": "user=${localUser.email}"
}
}]Caso especial de ejecución local
La ejecución local de aplicaciones o scripts con commandType: «file» en Rainbow Desktop no está sujeta a las restricciones CORS del navegador, al acceso a la red local ni a los encabezados de seguridad de iframe.
Problemas habituales y solución de incidencias
Aparece una advertencia al cargar el manifiesto
El manifiesto hace referencia a una o varias URL cuyo origen no está declarado en la consola.
Solución: Añada el origen que falta en Empresa → Personalización → Dominios de manifiestos personalizados.
Una llamada REST no produce ningún resultado
| Causa probable | Cómo comprobarlo | Solución |
| Dominio no declarado | Advertencia al cargar el manifiesto | Declare el origen en la consola |
| Faltan los encabezados CORS | Herramientas de desarrollador → Pestaña «Red» → Error CORS | Añada «Access-Control-Allow-Origin» en el servidor |
| LNA (servidor local) | Funciona en el escritorio, pero no en la web | Exponer a través de HTTPS o utilizar la versión de escritorio |
El marco permanece en blanco
| Causa probable | Cómo comprobarlo | Solución |
| Dominio no declarado | Advertencia al cargar el manifiesto | Declare el origen en la consola |
| X-Frame-Options o CSP restrictivos | Herramientas de desarrollador → encabezados de respuesta | Modifique los encabezados en la aplicación o utilice Popup: true |
| Dominio del IdP de SSO no declarado | El marco se queda en blanco durante el proceso de inicio de sesión | Declare también el dominio del IdP |
| El IdP rechaza los iframes | El marco permanece en blanco tras la declaración del dominio | Cambie a «Popup: true» |
Lista de comprobación de diagnóstico
- El origen se ha declarado en Empresa → Personalización → Dominios del manifiesto personalizado
- El servidor REST devuelve encabezados CORS (Access-Control-Allow-Origin)
- El servidor no se encuentra en una red local o privada (LNA — Solo web)
- La aplicación integrada no devuelve valores restrictivos para X-Frame-Options ni CSP: frame-ancestors
- Para SSO / OAuth: los dominios del IdP también están declarados como de confianza
- Si nada de lo anterior funciona: Popup: true comprobado para marcos; Desktop comprobado para llamadas REST locales