Connexion à Salesforce CLI via un VPN : CLI, navigateur et hôte API

Les échecs de connexion à Salesforce CLI sont signalés comme un seul problème et sont généralement trois. Le processus CLI s’exécute quelque part, le navigateur qui termine le flux web s’exécute quelque part, et l’appel API ultérieur s’exécute quelque part, et ces trois endroits n’ont pas besoin de partager une route, un résolveur ou une liste d’autorisations. Les comparer est le moyen le plus rapide de savoir lequel le tunnel bloque réellement. Rien dans la sortie de connexion n’indique lequel des trois a échoué.

Trois hôtes, une seule histoire de connexion

Le flux de connexion web confie l’étape d’identité à un navigateur, et ce navigateur est souvent sur votre ordinateur portable tandis que la CLI se trouve sur un hôte de développement distant ou dans un conteneur. L’ordinateur portable a le client VPN, l’hôte distant a ce que l’équipe plateforme lui a donné, et aucune des deux dispositions ne couvre automatiquement l’autre. Une icône VPN dans la barre d’état ne dit rien d’un hôte qui n’a jamais lancé le client.

Après la connexion, la CLI fait ses propres requêtes API depuis là où vit le processus. Ces requêtes ont besoin de DNS, de routage, de confiance TLS et d’autorisation client côté org, soit quatre vérifications distinctes et chacune peut échouer seule. Un navigateur qui s’est connecté parfaitement ne vous dit rien sur aucune d’elles.

Gardez les deux moitiés sur une même chronologie, mais notez-les séparément. Un seul ticket peut alors dire quelle moitié a cassé sans que cela devienne un débat sur la propriété.

Prenez l’entrée de l’org auprès de l’org, pas de mémoire

Le flux web prend une URL d’instance et stocke le résultat sous un alias, et les deux valeurs doivent venir du propriétaire de l’org plutôt que de l’historique de terminal d’un collègue. Un hôte sandbox copié depuis un ancien ticket est une cause courante d’une connexion qui s’authentifie contre la mauvaise org puis échoue à chaque requête.

Utilisez la forme que documente le plugin installé, avec votre propre hôte et alias approuvés. Cette documentation est la référence pour les options qui ont changé entre sfdx et la CLI actuelle.

sf org login web --instance-url https://acme--uat.sandbox.my.salesforce.com --alias uat
sf org display --target-org uat

Le nom d’hôte et l’alias ci-dessus sont des exemples, pas des valeurs par défaut que vous devriez copier. Effectuez les étapes normales d’identité du navigateur et de MFA au lieu de les contourner par script, et ne placez jamais un mot de passe, un identifiant de session ou une graine d’authentificateur dans une commande shell pour éviter l’invite.

Ce que prouve l’autorisation en cache

Un alias qui apparaît dans la liste d’autorisations locale prouve qu’une connexion a réussi une fois sur cette machine. La liste est lue depuis le stockage local et ne contacte pas l’org pour confirmer que le jeton fonctionne encore, donc une entrée d’apparence saine et un appel API rejeté peuvent être vrais en même temps. Traitez le cache comme un enregistrement du passé, pas comme un test de connectivité en direct. Une vérification du cache répond à une question de support, mais elle ne clôt jamais une enquête de connectivité.

La même distinction s’applique à la session du navigateur. Un onglet qui affiche encore l’org ne signifie pas que le jeton stocké de la CLI correspond à la politique actuelle, car la durée de vie du jeton, les restrictions IP et les règles de l’application cliente s’appliquent à la frontière de l’API.

Lisez l’enregistrement local avant de le supprimer, car l’alias et l’hôte de l’org sont les deux faits que le support demandera. Supprimer un alias est réversible, mais supprimer le mauvais au milieu d’un incident ne fait qu’ajouter un second problème.

Où la requête API est réellement rejetée

Suivez une requête de bout en bout et notez quel composant répond. Un échec TLS nomme un problème différent d’un 403, qui nomme un problème différent d’un délai d’attente, et le délai d’attente est le seul des trois qui désigne le tunnel comme premier suspect. Lire la classe d’erreur avant le message économise beaucoup de conjectures. Notez la classe avant de relancer quoi que ce soit.

Les restrictions d’adresse source sont le cas qui produit une connexion qui marche et une requête qui ne marche pas, car le flux du navigateur et l’appel API peuvent sortir par des adresses différentes. Corriger cela avec une liste d’autorisations plus large est une décision du propriétaire de l’org, pas une commodité, et ce devrait être la plus petite plage qui couvre l’hôte.

Capturez la commande qui échoue, l’alias, l’hôte d’exécution et l’horodatage, et laissez le jeton en dehors de tout ce que vous collez dans le ticket. Ce résumé en quatre lignes est ce dont le propriétaire de l’org a besoin pour vérifier son côté.

Vérifiez le flux depuis l’hôte qui l’utilisera

Testez depuis la machine qui exécutera la charge de travail. Une connexion vérifiée sur votre ordinateur portable ne dit rien d’un agent de build dans une autre zone réseau, et la différence est exactement ce que vous cherchez à trouver.

Utilisez une lecture autorisée inoffensive pour la vérification, et conservez la première erreur si elle échoue.

sf org list auth
sf org display --target-org uat
sf data query --target-org uat --query "select Id, Name from Organization"

Quand la connexion réussit mais que la requête échoue, les candidats restants sont DNS, routage, interception TLS et politique client côté org, et chacun a son propre propriétaire. Quand la connexion elle-même échoue, le navigateur et la CLI ne sont probablement pas sur le même hôte, et le correctif relève de la disposition entre eux plutôt que du tunnel. L’automatisation reçoit une règle de plus : une tâche non surveillée a besoin d’une connexion approuvée basée sur certificat, car une session interactive en cache copiée sur un worker n’est pas une conception d’identité.