Inici de sessió de Salesforce CLI a través d'una VPN: CLI, navegador i host d'API

Els errors d'inici de sessió de Salesforce CLI es reporten com un sol problema i normalment són tres. El procés de la CLI s'executa en algun lloc, el navegador que completa el flux web s'executa en algun lloc, i la crida posterior a l'API s'executa en algun lloc, i aquests tres llocs no han de compartir ruta, resolutor ni llista d'admesos. Comparar-los és la manera més ràpida de saber quin bloqueja realment el túnel. Res a la sortida de l'inici de sessió no indica quin dels tres ha fallat.

Tres hosts, una història d'inici de sessió

El flux web d'inici de sessió lliura el pas d'identitat a un navegador, i aquest navegador sovint és al vostre portàtil mentre la CLI és en un host de desenvolupament remot o en un contenidor. El portàtil té el client VPN, l'host remot té el que li va donar l'equip de plataforma, i cap dels dos arranjaments cobreix automàticament l'altre. Una icona de VPN a la barra d'estat no diu res sobre un host que mai ha executat el client.

Després de l'inici de sessió, la CLI fa les seves pròpies peticions a l'API des d'on viu el procés. Aquestes peticions necessiten DNS, encaminament, confiança TLS i autorització de client per part de l'org, que són quatre comprovacions separades i cadascuna pot fallar pel seu compte. Un navegador que ha iniciat sessió perfectament no us diu res sobre cap d'elles.

Mantingueu les dues meitats en una sola línia temporal, però puntueu-les per separat. Així un sol tiquet pot dir quina meitat s'ha trencat sense convertir-ho en una discussió sobre la propietat.

Preneu l'entrada de l'org de l'org, no de la memòria

El flux web pren un URL d'instància i desa el resultat sota un àlies, i tots dos valors haurien de venir del propietari de l'org i no de l'historial de terminal d'un company. Un host de sandbox copiat d'un tiquet antic és una causa comuna d'un inici de sessió que s'autentica contra l'org equivocat i després falla en cada consulta.

Feu servir la forma que documenta el connector instal·lat, amb el vostre host i àlies aprovats. Aquesta documentació és la referència per a les opcions que van canviar entre sfdx i la CLI actual.

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

El nom d'host i l'àlies de dalt són exemples, no valors per defecte que hàgiu de copiar. Completeu els passos normals d'identitat del navegador i de MFA en lloc d'envoltar-los amb scripts, i no poseu mai una contrasenya, un identificador de sessió o una llavor d'autenticador en una ordre d'intèrpret per saltar-vos l'avís.

Què demostra l'autorització en memòria cau

Un àlies que apareix a la llista d'autoritzacions local demostra que un inici de sessió va reeixir una vegada en aquella màquina. La llista es llegeix de l'emmagatzematge local i no contacta l'org per confirmar que el testimoni encara funciona, així que una entrada d'aspecte saludable i una crida a l'API rebutjada poden ser certes alhora. Tracteu la memòria cau com un registre del passat, no com una prova de connectivitat en directe. Una comprovació de la memòria cau respon una pregunta de suport, però mai no tanca una investigació de connectivitat.

La mateixa distinció s'aplica a la sessió del navegador. Una pestanya que encara mostra l'org no vol dir que el testimoni desat de la CLI coincideixi amb la política actual, perquè la vida del testimoni, les restriccions per IP i les regles de l'aplicació client s'apliquen a la frontera de l'API.

Llegiu el registre local abans d'esborrar-lo, ja que l'àlies i l'host de l'org són els dos fets que el suport demanarà. Eliminar un àlies és reversible, però eliminar l'equivocat enmig d'un incident només afegeix un segon problema.

On es rebutja realment la petició a l'API

Seguiu una petició de cap a peus i anoteu quin component respon. Un error TLS anomena un problema diferent d'un 403, que anomena un problema diferent d'un temps d'espera, i el temps d'espera és l'únic dels tres que assenyala el túnel com a primer sospitós. Llegir la classe d'error abans del missatge estalvia moltes conjectures. Anoteu la classe abans de tornar a executar res.

Les restriccions d'adreça d'origen són el cas que produeix un inici de sessió que funciona i una consulta que no, perquè el flux del navegador i la crida a l'API poden sortir per adreces diferents. Arreglar-ho amb una llista d'admesos més àmplia és una decisió del propietari de l'org, no una comoditat, i hauria de ser el rang més petit que cobreixi el host.

Captureu l'ordre que falla, l'àlies, el host d'execució i la marca de temps, i deixeu el testimoni fora de tot el que enganxeu al tiquet. Aquest resum de quatre línies és el que el propietari de l'org necessita per comprovar el seu costat.

Comproveu el flux des del host que l'utilitzarà

Proveu des de la màquina que executarà la càrrega de treball. Un inici de sessió verificat al vostre portàtil no diu res sobre un agent de compilació en una altra zona de xarxa, i la diferència és exactament el que intenteu trobar.

Feu servir una lectura autoritzada inofensiva per a la comprovació, i conserveu el primer error si falla.

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

Quan l'inici de sessió reïx però la consulta falla, els candidats restants són DNS, encaminament, intercepció de TLS i política de client per part de l'org, i cadascun té el seu propietari. Quan falla el mateix inici de sessió, el navegador i la CLI probablement no són al mateix host, i la solució pertany a l'arranjament entre ells i no al túnel. L'automatització rep una regla més: una tasca no supervisada necessita un inici de sessió aprovat basat en certificat, perquè una sessió interactiva en memòria cau copiada a un worker no és un disseny d'identitat.