Gestion des domaines de confiance et de la sécurité du réseau

Cet article vous permettra de sécuriser les URL externes utilisées par vos extensions « custo-manifest ». Vous découvrirez comment déclarer des domaines de confiance, configurer le CORS ou l'accès au réseau local si nécessaire, et diagnostiquer les requêtes bloquées.

Présentation

Les extensions « custo-manifest » peuvent accéder à des URL externes : appels à l’API REST, applications web intégrées dans un cadre Rainbow ou chargement de contenu dynamique. Afin de contrôler quels serveurs tiers peuvent être contactés, Rainbow applique une liste blanche de domaines de confiance configurée dans la console d’administration Rainbow.

Tout domaine ne figurant pas dans cette liste est bloqué. Selon le type d’extension concerné, ce blocage se manifeste différemment ; c’est pourquoi il est Essential de bien comprendre ce mécanisme avant de déployer un manifeste.

Configuration des domaines de confiance

La liste est gérée dans la console d’administration de Rainbow :

Compagnie → Informations → Personnalisation → Domaines du manifeste personnalisé

Console Rainbow — Personnalisation → onglet « Domaines de manifestes personnalisés »

Ajoutez une entrée par origine à autoriser. Chaque entrée doit respecter le format suivant :

<protocole>://<domaine>[:<port>]

Exemples valides

Exemples non valides

Portée du domaine de confiance

La vérification du domaine de confiance s’applique de manière cohérente aux URL utilisées par les extensions Rainbow sur le Web et sur ordinateur.

Impact sur les appels à l'API REST

Les extensions qui appellent une API REST (commandType : « rest ») passent par le navigateur. Deux couches de sécurité indépendantes s’appliquent :

Vérification du domaine de confiance (côté Rainbow)

Si l’origine du serveur REST n’est pas déclarée dans la console Rainbow, Rainbow affiche un avertissement lors du chargement du manifeste. Si l’avertissement est ignoré, l’appel échouera silencieusement lors de l’exécution — aucun message d’erreur ne s’affichera dans Rainbow.

Solution : déclarez l’origine dans Compagnie → Personnalisation → Domaines du manifeste personnalisé.

CORS (côté serveur REST)

Même si le domaine est considéré comme fiable par Rainbow, le navigateur applique également les règles CORS. Le serveur REST doit renvoyer les en-têtes suivants dans ses réponses :

Access-Control-Allow-Origin : https://web.openrainbow.com
Access-Control-Allow-Methods : GET, POST, OPTIONS
Access-Control-Allow-Headers : Content-Type, Authorization

Si vous n’avez pas besoin de restreindre l’accès à une origine spécifique, vous pouvez utiliser le caractère générique :

Access-Control-Allow-Origin : *

Si le serveur ne renvoie pas ces en-têtes, le navigateur bloque l’appel sans afficher de message dans Rainbow. Si vous contrôlez le serveur, ajoutez les en-têtes CORS. Sinon, demandez au propriétaire du serveur de mettre à jour sa configuration.

Accès au réseau local (LNA)

Si le serveur REST s’exécute sur un réseau local ou privé (par exemple http://192.168.1.100:3300), le navigateur peut bloquer l’appel en vertu de la politique d’accès au réseau local.

Lorsque le navigateur détecte une requête vers un réseau privé, il envoie d’abord une requête OPTIONS préliminaire avec :

Access-Control-Request-Private-Network: true

Le serveur doit répondre en ajoutant Access-Control-Allow-Private-Network: true à ses en-têtes CORS :

Access-Control-Allow-Origin : https://web.openrainbow.com
Access-Control-Allow-Methods : GET, POST, OPTIONS
Access-Control-Allow-Private-Network : true

Si cet en-tête est absent, le navigateur bloque la requête même si les en-têtes CORS standard sont corrects.

Solutions en fonction du contexte :

Impact sur les applications intégrées

L’extension « on-main-window-actions » affiche une application web tierce au sein de l’interface Rainbow. Deux modes sont disponibles en fonction de la valeur de « Popup ».

Sans « Popup » — application dans le cadre Rainbow

L’application est chargée dans un <IFRAME> au sein de Rainbow. Trois niveaux de sécurité s’appliquent :

Domaines de confiance

L’URL de l’application doit être déclarée dans la console Rainbow. À défaut, le cadre s’affiche mais la page reste vide ou affiche une erreur de sécurité du navigateur.

CSP / X-Frame-Options de l’application

L’application cible peut elle-même refuser d’être intégrée dans une iframe :

Comment vérifier : Outils de développement → onglet Réseau → réponse provenant de l’URL de l’application → inspecter les en-têtes.

Solution : si vous contrôlez l’application, autorisez l’origine Rainbow dans frame-ancestors. Sinon, passez à Popup: true (voir §3.2).

Flux SSO / OAuth via un domaine tiers

Si l’application utilise un flux d’authentification (SSO, OAuth 2.0, SAML…), le fournisseur d’identité (IdP) se trouve généralement sur un domaine différent de celui de l’application. Rainbow charge ces redirections au sein du même cadre — tous les domaines du flux doivent donc être déclarés :

https://app.example.com ← l’application
https://login.microsoftonline.com ← IdP Microsoft
https://login.example.com ← votre IdP interne

Avec Popup: true — l’application s’ouvre dans une fenêtre dédiée

Lorsque « Popup: true » est défini, l’URL s’ouvre dans une fenêtre de navigateur dédiée, en dehors du cadre Rainbow. Dans ce mode :

• la vérification du domaine de confiance de Rainbow est désactivée pour cette URL.
• Les restrictions X-Frame-Options et CSP « frame-ancestors » de l’application ne s’appliquent pas.
• Les flux SSO / OAuth fonctionnent normalement dans leur propre fenêtre.

"on-main-window-actions": [{
"name": "My App",
"icon": "${custo.path}\\app.png",
"Popup": true,
"command": {
"url": "https://app.example.com/",
"params": "user=${localUser.email}"
}
}]

Cas particulier de l’exécution locale

L’exécution locale d’une application ou d’un script avec commandType : « file » sur Rainbow Desktop n’est pas soumise aux restrictions CORS du navigateur, à l’accès au réseau local ni aux en-têtes de sécurité iframe.

Problèmes courants et dépannage

Un avertissement s'affiche lors du chargement du manifeste

Le manifeste fait référence à une ou plusieurs URL dont l’origine n’est pas déclarée dans la console.

Solution : ajoutez l’origine manquante dans Compagnie → Personnalisation → Domaines du manifeste personnalisé.

Un appel REST ne produit aucun résultat

Le cadre reste vide

Liste de contrôle de diagnostic

• L'origine est déclarée dans Compagnie → Personnalisation → Domaines du manifeste personnalisé
• Le serveur REST renvoie des en-têtes CORS (Access-Control-Allow-Origin)
• Le serveur ne se trouve pas sur un réseau local/privé (LNA — Web uniquement)
• L’application intégrée ne renvoie pas d’en-têtes X-Frame-Options restrictifs ni de CSP : frame-ancestors
• Pour l’authentification unique (SSO) / OAuth : les domaines IdP sont également déclarés comme fiables
• Si rien d’autre ne fonctionne : Popup : true testé pour les cadres, Desktop testé pour les appels REST locaux