Bonnes pratiques pour les extensions Rainbow

Vous pouvez utiliser cet article comme liste de contrôle avant de créer, de tester ou de déployer un manifeste personnalisé en production. Utilisez-le pour que votre manifeste reste facile à maintenir, sécurisé et plus simple à dépanner.

Création

• Partez d’un modèle exporté depuis Rainbow Desktop ou d’un manifeste déjà validé.
• Supprimez les points d'extension inutilisés avant le déploiement en production.
• Conservez la version définie sur « 2 » et le jsonType sur « Rainbow-custo-manifest ».
• Ne définissez pas plus de 3 actions pour un même point d’extension.
• Évitez les chemins d'accès codés en dur provenant d'un poste de développement. Utilisez ${custo.path} et regroupez les ressources dans une archive ZIP.

Sécurité

• Déclarez toutes les origines REST et iframe dans les domaines Custo-manifest avant le déploiement.
• Privilégiez les points de terminaison HTTPS avec des noms DNS stables.
• Pour les API REST, configurez explicitement le CORS et testez les requêtes de pré-vérification du navigateur.
• Pour les serveurs en réseau local/privé, vérifiez le comportement de Rainbow Web à l’aide des règles d’accès au réseau local.
• N’intégrez pas de secrets directement dans un manifeste distribué à vos utilisateurs. Privilégiez, dans la mesure du possible, les jetons côté serveur ou les identifiants à durée de vie limitée.

Variables

• Utilisez la variable la plus restrictive disponible pour le point d’extension.
• Testez les variables avec des appels, des Contacts et des Bulles réalistes ; certaines valeurs sont vides lorsque le contexte fait défaut.
• N’utilisez les expressions régulières que pour des transformations simples. Les transformations complexes doivent être effectuées côté serveur.
• Vérifiez les formats des numéros de téléphone sur les déploiements Cloud PBX, OmniPCX Enterprise et OXO Connect.

Cartes adaptatives

• Veillez à ce que les cartes soient concises et axées sur l’action de l’utilisateur.
• Testez l’affichage sur Rainbow Web et Rainbow Desktop.
• Évitez les éléments Adaptive Card 1.6+ non pris en charge, sauf si la version cible du client Rainbow les prend explicitement en charge.
• Pour Action.Submit, veillez à ce que le point de terminaison cible soit idempotent et fournissez un retour d’information clair à l’utilisateur.

Validation avant mise en production

• Vérifiez la syntaxe JSON.
• Testez l’importation locale avant le déploiement centralisé.
• Testez le manifeste sur le Web et sur ordinateur de bureau lorsque les deux clients sont ciblés.
• Vérifiez tous les domaines de confiance, les en-têtes CORS et les en-têtes iframe.
• Déployez d’abord auprès d’un utilisateur ou d’un profil pilote avant de procéder à un déploiement à plus grande échelle.
• Conservez une copie du manifeste précédent afin de pouvoir revenir immédiatement à la version précédente.