Autentificare în Salesforce CLI prin VPN: CLI, browser și gazdă API

Eșecurile de autentificare în Salesforce CLI sunt raportate ca o singură problemă și de obicei sunt trei. Procesul CLI rulează undeva, browserul care finalizează fluxul web rulează undeva, iar apelul API ulterior rulează undeva, și acele trei locuri nu trebuie să partajeze o rută, un resolver sau o listă de permisiuni. Compararea lor este cea mai rapidă cale de a afla pe care dintre ele îl blochează tunelul de fapt. Nimic din ieșirea autentificării nu spune care dintre cele trei a eșuat.

Trei gazde, o singură poveste de autentificare

Fluxul de autentificare web predă pasul de identitate unui browser, iar acel browser este adesea pe laptop în timp ce CLI-ul stă pe o gazdă de dezvoltare la distanță sau într-un container. Laptopul are clientul VPN, gazda la distanță are ce i-a dat echipa de platformă, și niciuna dintre cele două aranjamente nu o acoperă automat pe cealaltă. O pictogramă VPN în bara de stare nu spune nimic despre o gazdă care nu a rulat niciodată clientul.

După autentificare, CLI-ul face propriile cereri API din locul unde trăiește procesul. Acele cereri au nevoie de DNS, rutare, încredere TLS și autorizare a clientului din partea org, care sunt patru verificări separate și fiecare poate eșua singură. Un browser care s-a autentificat frumos nu vă spune nimic despre niciuna dintre ele.

Țineți ambele jumătăți pe o singură linie de timp, dar evaluați-le separat. Atunci un singur tichet poate spune care jumătate s-a rupt fără a transforma asta într-o dezbatere despre proprietate.

Luați înregistrarea org de la org, nu din memorie

Fluxul web ia un URL de instanță și stochează rezultatul sub un alias, iar ambele valori ar trebui să vină de la proprietarul org, nu din istoricul terminalului unui coleg. O gazdă sandbox copiată dintr-un tichet vechi este o cauză obișnuită a unei autentificări care se validează împotriva org greșite și apoi eșuează la fiecare interogare.

Folosiți forma documentată de pluginul instalat, cu gazda și aliasul dumneavoastră aprobate. Acea documentație este referința pentru steagurile care s-au schimbat între sfdx și CLI-ul actual.

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

Numele gazdei și aliasul de mai sus sunt exemple, nu valori implicite pe care ar trebui să le copiați. Finalizați pașii obișnuiți de identitate ai browserului și MFA în loc să îi ocoliți cu un script, și nu puneți niciodată o parolă, un identificator de sesiune sau o sămânță de autentificator într-o comandă shell pentru a sări peste solicitare.

Ce dovedește autorizarea din cache

Un alias care apare în lista de autorizări locală dovedește că o autentificare a reușit cândva pe acea mașină. Lista este citită din stocarea locală și nu contactează org pentru a confirma că tokenul încă funcționează, așa că o intrare cu aspect sănătos și un apel API respins pot fi ambele adevărate. Tratați cache-ul ca pe o înregistrare a trecutului, nu ca pe un test de conectivitate în direct. O verificare a cache-ului răspunde la o întrebare de suport, dar nu închide niciodată o investigație de conectivitate.

Aceeași distincție se aplică sesiunii browserului. Un tab care încă afișează org nu înseamnă că tokenul stocat al CLI-ului corespunde politicii actuale, deoarece durata de viață a tokenului, restricțiile IP și regulile aplicației client sunt aplicate la granița API.

Citiți înregistrarea locală înainte de a o șterge, deoarece aliasul și gazda org sunt cele două fapte pe care le va cere suportul. Eliminarea unui alias este reversibilă, dar eliminarea celui greșit în mijlocul unui incident adaugă doar o a doua problemă.

Unde este respinsă de fapt cererea API

Urmați o cerere de la început până la sfârșit și notați ce componentă răspunde. O eroare TLS numește o problemă diferită de un 403, care numește o problemă diferită de un timeout, iar timeoutul este singurul dintre cele trei care indică tunelul ca prim suspect. Citirea clasei de eroare înaintea mesajului economisește multe presupuneri. Notați clasa înainte de a rula din nou ceva.

Restricțiile de adresă sursă sunt cazul care produce o autentificare care funcționează și o interogare care nu, deoarece fluxul browserului și apelul API pot ieși prin adrese diferite. Corectarea acestui lucru cu o listă de permisiuni mai largă este o decizie a proprietarului org, nu o comoditate, și ar trebui să fie cel mai mic interval care acoperă gazda.

Înregistrați comanda care eșuează, aliasul, gazda de execuție și marcajul temporal, și lăsați tokenul în afara a tot ce lipiți în tichet. Acel rezumat de patru rânduri este ce are nevoie proprietarul org pentru a-și verifica partea.

Verificați fluxul de pe gazda care îl va folosi

Testați de pe mașina care va rula sarcina de lucru. O autentificare verificată pe laptop nu spune nimic despre un agent de build într-o altă zonă de rețea, iar diferența este exact ceea ce încercați să găsiți.

Folosiți o citire autorizată inofensivă pentru verificare, și păstrați prima eroare dacă eșuează.

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

Când autentificarea reușește dar interogarea eșuează, candidații rămași sunt DNS, rutare, interceptare TLS și politica de client din partea org, și fiecare are propriul proprietar. Când autentificarea în sine eșuează, browserul și CLI-ul probabil nu sunt pe aceeași gazdă, iar corectarea aparține aranjamentului dintre ele, nu tunelului. Automatizarea primește încă o regulă: un job nesupravegheat are nevoie de o autentificare aprobată bazată pe certificat, pentru că o sesiune interactivă din cache copiată pe un worker nu este un design de identitate.