Origines SDK

SDK origins est la liste d’autorisation des applications de navigateur qui appellent Thalovant à partir d’un site qui vous appartient.

Servez-vous-en seulement quand un environnement de navigateur doit faire des requêtes SDK ou API d’une origine à une autre. Pour les services, les agents, les outils en ligne de commande et les tâches, continuez d’utiliser un serveur ou un environnement protégé doté d’un magasin de secrets.

Les espaces de travail gratuits n’ont pas besoin de SDK origins pour le parcours vocal de départ. Commencez par Public hubs et Connections; SDK origins apparaît quand le forfait de l’espace de travail permet la revue des origines de navigateur.

Comment ça fonctionne

1. Ouvrez SDK origins dans le tableau de bord.
2. Choisissez l’espace de travail à qui appartient l’application de navigateur.
3. Demandez une origine exacte, comme https://app.example.com.
4. Attendez la revue. Une personne chargée de la revue dans l’espace de travail reçoit une notification et un courriel.
5. Utilisez l’origine approuvée. Les requêtes de navigateur venant de cette origine peuvent utiliser CORS sans identifiants.

Une origine contient https://, l’hôte et, au besoin, le port. Rien d’autre : pas de chemin, de paramètres de requête, de fragment, de caractère générique, de http:// ni de null.

Ce que l’approbation permet

Permet	Ne permet pas
Les appels d’API d’une origine à une autre à partir de l’origine exacte approuvée.	Les témoins du tableau de bord ni les flux de rafraîchissement de session à partir de sites clients.
Les en-têtes de requête Authorization et Idempotency-Key.	Les en-têtes CSRF ni les en-têtes de rafraîchissement propres au tableau de bord.
Les requêtes du SDK de navigateur venant d’un domaine de production connu.	Les domaines génériques, les fichiers locaux ni les origines avec chemin et paramètres de requête.

Attention

L’approbation ne sert qu’à la vérification de l’origine par le navigateur. Elle ne rend pas sûrs les identités de hub, les jetons d’API, les liens de configuration ni les mots de passe du courtier placés dans du JavaScript servi aux utilisateurs.

Un modèle sûr pour le navigateur

Passez par un serveur quand le navigateur a besoin de secrets.

Bon usage

Une application web appelle une petite surface d’API approuvée avec une authentification d’utilisateur de courte durée, sans identité de hub de longue durée dans le paquet.

Passez par un serveur

La création et le stockage des identités, le matériel de configuration, les mots de passe du courtier, les sessions de rafraîchissement et les paiements restent côté serveur.

Faites approuver chaque domaine

Demandez séparément les domaines de production, de préproduction et d’aperçu. Désactivez les origines qui ne servent plus l’application.

SDK locaux et serveurs

SDK origins n’est pas la frontière de sécurité du code qui tourne sur un portable, un service côté serveur, une tâche d’intégration continue, un appareil de pièce ou un serveur privé.

Environnement	SDK origins?	Modèle plus sûr
Script ou outil en ligne de commande sur un portable	Non	Rangez le fichier d’identité hors du dépôt et limitez-le à l’utilisateur courant.
Service côté serveur ou tâche	Non	Gardez les jetons, le matériel de configuration et l’identité du hub dans un magasin de secrets côté serveur.
Appareil Thalovant Voice	Non	Utilisez le lien de configuration privé ou la commande d’installation générée dans Connections.
Application de navigateur d’un client	Oui	Demandez séparément les origines exactes de production, de préproduction et d’aperçu.

Si une application de navigateur a besoin d’une opération secrète, placez cette opération derrière votre serveur et appelez ce serveur à partir du navigateur.

Notifications

Quand une origine est demandée, la personne qui la demande et celle qui fait la revue voient une notification de sécurité. Un courriel est aussi envoyé pour que la personne chargée de la revue ouvre le tableau de bord et tranche.

Une fois la revue terminée, la personne qui a fait la demande reçoit une notification d’état et un courriel. Les origines approuvées fonctionnent dès que le cache CORS se rafraîchit.

Si le navigateur est refusé

Symptôme	Vérification
La requête préliminaire du navigateur renvoie 400	Confirmez que l’origine exacte est approuvée et qu’elle utilise https://.
Ça marche en préproduction, pas en production	Demandez l’origine de production séparément.
Les requêtes avec identifiants échouent	Réservez au tableau de bord les flux à base de témoins; les origines clientes sont sans identifiants.
X-CSRF-Token est refusé	Retirez des requêtes SDK origins les en-têtes propres au tableau de bord.
L’application a déménagé sur un nouveau domaine	Demandez la nouvelle origine, attendez la revue, puis désactivez l’ancienne.

Prêt quand

L’origine SDK est prête quand :

• l’origine est exacte et approuvée;
• le navigateur n’envoie que des en-têtes pris en charge;
• les secrets de longue durée restent hors du paquet du navigateur;
• les origines de préproduction et de production sont suivies séparément;
• les origines anciennes ou inutilisées sont désactivées.