Salesforce CLI-innlogging over en VPN: CLI, nettleser og API-vert

Feil ved Salesforce CLI-innlogging rapporteres som ett problem og er vanligvis tre. CLI-prosessen kjører et sted, nettleseren som fullfører webflyten kjører et sted, og det senere API-kallet kjører et sted, og disse tre stedene trenger ikke dele en rute, en resolver eller en tillatelsesliste. Å sammenligne dem er den raskeste måten å finne ut hvilken tunnelen faktisk blokkerer. Ingenting i innloggingsutdataene sier hvilken av de tre som feilet.

Tre verter, én innloggingshistorie

Webinnloggingsflyten overlater identitetstrinnet til en nettleser, og den nettleseren er ofte på den bærbare maskinen mens CLI-en sitter på en ekstern utviklingsvert eller i en container. Den bærbare har VPN-klienten, den eksterne verten har det plattformteamet ga den, og ingen av de to ordningene dekker automatisk den andre. Et VPN-ikon i statuslinjen sier ingenting om en vert som aldri kjørte klienten.

Etter innlogging lager CLI-en sine egne API-forespørsler fra der prosessen lever. Disse forespørslene trenger DNS, ruting, TLS-tillit og klientautorisasjon på org-siden, som er fire separate sjekker, og hver av dem kan feile alene. En nettleser som logget inn vakkert, forteller deg ingenting om noen av dem.

Hold begge halvdeler på én tidslinje, men vurder dem hver for seg. Da kan én sak si hvilken halvdel som brakk uten at det blir en diskusjon om eierskap.

Ta org-oppføringen fra org-en, ikke fra hukommelsen

Webflyten tar en instans-URL og lagrer resultatet under et alias, og begge verdiene bør komme fra org-eieren i stedet for fra en kollegas terminalhistorikk. En sandbox-vert kopiert fra en gammel sak er en vanlig årsak til en innlogging som autentiserer mot feil org og deretter feiler på hver spørring.

Bruk formen som det installerte tillegget dokumenterer, med din egen godkjente vert og alias. Den dokumentasjonen er referansen for flagg som endret seg mellom sfdx og gjeldende CLI.

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

Vertnavnet og aliaset ovenfor er eksempler, ikke standardverdier du bør kopiere. Fullfør de vanlige nettleseridentitets- og MFA-trinnene i stedet for å gå utenom dem med et skript, og legg aldri et passord, en sesjonsidentifikator eller en autentiseringsfrø i en skallkommando for å hoppe over forespørselen.

Hva den bufrede autorisasjonen beviser

Et alias som vises i den lokale autorisasjonslisten, beviser at en innlogging en gang lyktes på den maskinen. Listen leses fra lokal lagring og kontakter ikke org-en for å bekrefte at tokenet fortsatt virker, så en sunn utseende oppføring og et avvist API-kall kan begge være sanne. Behandle cachen som en registrering av fortiden, ikke som en test av den levende tilkoblingen. En cache-sjekk svarer på et støttespørsmål, men den lukker aldri en tilkoblingsundersøkelse.

Den samme forskjellen gjelder nettleserøkten. En fane som fortsatt viser org-en, betyr ikke at CLIs lagrede token samsvarer med gjeldende policy, fordi tokenlevetid, IP-begrensninger og klientapp-regler håndheves ved API-grensen.

Les den lokale oppføringen før du sletter den, siden aliaset og org-verten er de to fakta støtten vil spørre om. Å fjerne et alias er reversibelt, men å fjerne det gale midt i en hendelse legger bare til et andre problem.

Hvor API-forespørselen faktisk avvises

Følg én forespørsel fra start til slutt og noter hvilken komponent som svarer. En TLS-feil navngir et annet problem enn en 403, som navngir et annet problem enn en timeout, og en timeout er den eneste av de tre som peker på tunnelen som første mistenkte. Å lese feilklassen før meldingen sparer mye gjetting. Skriv ned klassen før du kjører noe på nytt.

Kildeadressebegrensninger er tilfellet som gir en innlogging som virker og en spørring som ikke gjør det, fordi web-flyten og API-kallet kan gå ut gjennom forskjellige adresser. Å rette det med en bredere tillatelsesliste er org-eierens beslutning, ikke en bekvemmelighet, og det bør være det minste området som dekker verten.

Registrer kommandoen som feiler, aliaset, utførelsesverten og tidsstempelet, og hold tokenet utenfor alt du limer inn i saken. Det fireslinjers sammendraget er det org-eieren trenger for å sjekke sin side.

Sjekk flyten fra verten som skal bruke den

Test fra maskinen som skal kjøre arbeidsbelastningen. En innlogging verifisert på den bærbare sier ingenting om en byggeagent i en annen nettverkssone, og forskjellen er nøyaktig det du prøver å finne.

Bruk en ufarlig godkjent lesing for sjekken, og behold den første feilen hvis den feiler.

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

Når innloggingen lykkes men spørringen feiler, er de gjenværende kandidatene DNS, ruting, TLS-avlytting og klientpolicy på org-siden, og hver har sin egen eier. Når selve innloggingen feiler, er nettleseren og CLI-en sannsynligvis ikke på samme vert, og rettelsen hører til ordningen mellom dem snarere enn til tunnelen. Automatisering får én regel til: en uovervåket jobb trenger en godkjent sertifikatbasert innlogging, fordi en bufret interaktiv økt kopiert til en worker ikke er en identitetsdesign.