Prijava na Salesforce CLI preko VPN-a: CLI, preglednik i API host

Greške prijave na Salesforce CLI prijavljuju se kao jedan problem, a obično su tri. CLI proces radi negdje, preglednik koji dovršava web tok radi negdje, a kasniji API poziv radi negdje, i ta tri mjesta ne moraju dijeliti rutu, resolver ili listu dozvola. Upoređivanje njih najbrži je način da saznate koje od njih tunel zapravo blokira. Ništa u izlazu prijave ne navodi koje je od tri propalo.

Tri hosta, jedna priča o prijavi

Web tok prijave predaje korak identiteta pregledniku, a taj je preglednik često na vašem laptopu dok CLI sjedi na udaljenom razvojnom hostu ili u kontejneru. Laptop ima VPN klijent, udaljeni host ima ono što mu je tim za platformu dao, i nijedan od tih aranžmana automatski ne pokriva drugi. Ikona VPN-a u statusnoj traci ne govori ništa o hostu koji nikada nije pokrenuo klijent.

Nakon prijave CLI šalje vlastite API zahtjeve s mjesta na kojem proces živi. Ti zahtjevi trebaju DNS, rutiranje, TLS povjerenje i klijentsku autorizaciju na strani org-a, što su četiri odvojene provjere od kojih svaka može zasebno propasti. Preglednik koji se lijepo prijavio ne govori vam ništa ni o jednoj od njih.

Držite obje polovine na jednoj vremenskoj liniji, ali ih ocjenjujte odvojeno. Tada jedan tiket može reći koja se polovina slomila, a da se to ne pretvori u raspravu o vlasništvu.

Unos org-a uzmite od org-a, ne iz sjećanja

Web tok uzima URL instance i sprema rezultat pod pseudonimom, a obje vrijednosti trebaju doći od vlasnika org-a, a ne iz terminalne historije kolege. Sandbox host kopiran sa starog tiketa čest je uzrok prijave koja se autentificira na pogrešan org i zatim propada na svakom upitu.

Koristite oblik koji dokumentira instalirani dodatak, s vlastitim odobrenim hostom i pseudonimom. Ta je dokumentacija referenca za zastavice koje su se promijenile između sfdx i trenutnog CLI-a.

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

Ime hosta i pseudonim iznad su primjeri, a ne zadane vrijednosti koje trebate kopirati. Dovršite uobičajene korake identiteta u pregledniku i MFA, umjesto da ih zaobilazite skriptom, i nikada ne stavljajte lozinku, identifikator sesije ili sjeme autentifikatora u shell naredbu da biste preskočili upit.

Šta keširana autorizacija dokazuje

Pseudonim koji se pojavljuje na lokalnoj listi autorizacija dokazuje da je prijava jednom uspjela na tom računaru. Lista se čita iz lokalne pohrane i ne kontaktira org da bi potvrdila da token još radi, pa zdravo izgledajući unos i odbijeni API poziv mogu biti istovremeno istiniti. Tretirajte keš kao zapis prošlosti, a ne kao test žive veze. Provjera keša odgovara na pitanje podrške, ali nikada ne zatvara istragu o povezanosti.

Ista razlika vrijedi i za sesiju preglednika. Kartica koja još pokazuje org ne znači da spremljeni token CLI-a odgovara trenutnoj politici, jer se trajanje tokena, IP ograničenja i pravila klijentske aplikacije provode na granici API-a.

Pročitajte lokalni zapis prije nego što ga izbrišete, jer su pseudonim i host org-a dvije činjenice koje će podrška tražiti. Uklanjanje pseudonima je reverzibilno, ali uklanjanje pogrešnog usred incidenta samo dodaje drugi problem.

Gdje se API zahtjev zapravo odbija

Pratite jedan zahtjev od početka do kraja i zabilježite koja komponenta odgovara. TLS neuspjeh imenuje drugačiji problem od 403, koji imenuje drugačiji problem od isteka vremena, a istek vremena je jedini od troje koji upućuje na tunel kao prvog osumnjičenog. Čitanje klase greške prije poruke štedi mnogo nagađanja. Zapišite klasu prije nego što bilo što ponovno pokrenete.

Ograničenja izvorne adrese slučaj je koji daje prijavu koja radi i upit koji ne radi, jer web tok i API poziv mogu izaći kroz različite adrese. Popravljanje toga širom listom dozvola odluka je vlasnika org-a, a ne pogodnost, i to bi trebao biti najmanji raspon koji pokriva host.

Zabilježite naredbu koja nije uspjela, pseudonim, host izvršavanja i vremensku oznaku, a token ostavite izvan svega što zalijepite u tiket. Taj sažetak od četiri retka ono je što vlasniku org-a treba da provjeri svoju stranu.

Provjerite tok s hosta koji će ga koristiti

Testirajte s računara koji će izvršavati radno opterećenje. Prijava provjerena na vašem laptopu ne govori ništa o build agentu u drugoj mrežnoj zoni, a razlika je upravo ono što pokušavate pronaći.

Za provjeru upotrijebite bezopasno odobreno čitanje i zadržite prvu grešku ako ne uspije.

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

Kada prijava uspije a upit ne uspije, preostali kandidati su DNS, rutiranje, TLS presretanje i klijentska politika na strani org-a, i svaki ima svog vlasnika. Kada sama prijava ne uspije, preglednik i CLI vjerojatno nisu na istom hostu, a popravak pripada aranžmanu između njih, a ne tunelu. Automatizacija dobija još jedno pravilo: nenadgledani posao treba odobrenu prijavu zasnovanu na certifikatu, jer keširana interaktivna sesija kopirana na radnika nije dizajn identiteta.