Salesforce CLI-innlogging over ein VPN: CLI, nettlesar og API-vert

Feil ved Salesforce CLI-innlogging blir rapporterte som eitt problem og er vanlegvis tre. CLI-prosessen køyrer ein stad, nettlesaren som fullfører webflyten køyrer ein stad, og det seinare API-kallet køyrer ein stad, og desse tre stadene treng ikkje dele ei rute, ein resolver eller ei tillatingsliste. Å samanlikne dei er den kvikkaste måten å finne ut kva for ein tunnelen faktisk blokkerer. Ingenting i innloggingsutdataene seier kva av dei tre som feila.

Tre vertar, éi innloggingshistorie

Webinnloggingsflyten overlèt identitetstrinnet til ein nettlesar, og den nettlesaren er ofte på den berbare maskinen medan CLI-en sit på ein ekstern utviklingsvert eller i ein container. Den berbare har VPN-klienten, den eksterne verten har det plattformteamet gav han, og ingen av dei to ordningane dekkjer automatisk den andre. Eit VPN-ikon i statuslinja seier ingenting om ein vert som aldri køyrde klienten.

Etter innlogging lagar CLI-en sine eigne API-førespurnader frå der prosessen lever. Desse førespurnadene treng DNS, ruting, TLS-tillit og klientautorisasjon på org-sida, som er fire separate sjekkar, og kvar av dei kan feile åleine. Ein nettlesar som logga inn vakkert, fortel deg ingenting om nokon av dei.

Hald båe halvdelane på éi tidslinje, men vurder dei kvar for seg. Då kan éi sak seie kva halvdel som braut utan at det blir ein diskusjon om eigarskap.

Ta org-oppføringa frå org-a, ikkje frå minnet

Webflyten tek ein instans-URL og lagrar resultatet under eit alias, og begge verdiane bør kome frå org-eigaren i staden for frå terminalhistoria til ein kollega. Ein sandbox-vert kopiert frå ei gammal sak er ein vanleg årsak til ei innlogging som autentiserer mot feil org og deretter feilar på kvar spørjing.

Bruk forma som det installerte tillegget dokumenterer, med din eigen godkjende vert og alias. Den dokumentasjonen er referansen for flagg som endra seg mellom sfdx og gjeldande CLI.

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

Vertnamnet og aliaset ovanfor er døme, ikkje standardverdiar du bør kopiere. Fullfør dei vanlege nettlesaridentitets- og MFA-trinnane i staden for å gå utanom dei med eit skript, og legg aldri eit passord, ein sesjonsidentifikator eller ein autentiseringsfrø i ein skallkommando for å hoppe over førespurnaden.

Kva den bufra autorisasjonen beviser

Eit alias som viser seg i den lokale autorisasjonslista, beviser at ei innlogging ein gong lukkast på den maskinen. Lista blir lesen frå lokal lagring og kontaktar ikkje org-a for å stadfeste at tokenet framleis verkar, så ein sunn utsjånad og eit avvist API-kall kan begge vere sanne. Handsame cachen som ein registrering av fortida, ikkje som ein test av den levande tilkoplinga. Ein cache-sjekk svarar på eit støttespørsmål, men han lukkar aldri ei tilkoplingsgransking.

Den same skilnaden gjeld nettlesarøkta. Ei fane som framleis viser org-a, tyder ikkje at det lagra tokenet til CLI-en svarar til gjeldande policy, fordi tokenlevetid, IP-avgrensingar og klientapp-reglar blir handheva ved API-grensa.

Les den lokale oppføringa før du slettar ho, sidan aliaset og org-verten er dei to fakta støtta vil spørje om. Å fjerne eit alias er reversibelt, men å fjerne det gale midt i ei hending legg berre til eit andre problem.

Kvar API-førespurnaden faktisk blir avvist

Følg éin førespurnad frå start til slutt og noter kva komponent som svarar. Ein TLS-feil nemner eit anna problem enn ein 403, som nemner eit anna problem enn ein timeout, og ein timeout er den einaste av dei tre som peikar på tunnelen som første mistenkte. Å lese feilklassen før meldinga sparar mykje gjetting. Skriv ned klassen før du køyrer noko på nytt.

Kjeldeadresse-avgrensingar er tilfellet som gir ei innlogging som verkar og ei spørjing som ikkje gjer det, fordi webflyten og API-kallet kan gå ut gjennom ulike adresser. Å rette det med ei breiare tillatingsliste er org-eigaren si avgjerd, ikkje ei bekvemmelegheit, og det bør vere det minste området som dekkjer verten.

Registrer kommandoen som feilar, aliaset, utføringsverten og tidsstempelet, og hald tokenet utanfor alt du limer inn i saka. Det fireslinja samandraget er det org-eigaren treng for å sjekke si side.

Sjekk flyten frå verten som skal bruke han

Test frå maskinen som skal køyre arbeidslasta. Ei innlogging stadfesta på den berbare seier ingenting om ein byggjeagent i ei anna nettverkssone, og skilnaden er nøyaktig det du prøver å finne.

Bruk ei ufarleg godkjend lesing for sjekken, og hald på den første feilen om han feilar.

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

Når innlogginga lukkast men spørjinga feilar, er dei attverande kandidatane DNS, ruting, TLS-avlytting og klientpolicy på org-sida, og kvar har sin eigen eigar. Når sjølve innlogginga feilar, er nettlesaren og CLI-en truleg ikkje på same vert, og rettinga høyrer til ordninga mellom dei snarare enn til tunnelen. Automasjon får éi regel meir: ein uovervaka jobb treng ei godkjend sertifikatbasert innlogging, fordi ei bufra interaktiv økt kopiert til ein worker ikkje er eit identitetsdesign.