Salesforce CLI-login over en VPN: CLI, browser og API-vært

Fejl ved Salesforce CLI-login rapporteres som ét problem og er normalt tre. CLI-processen kører et sted, browseren der fuldfører webforløbet kører et sted, og det senere API-kald kører et sted, og de tre steder behøver ikke dele en rute, en resolver eller en tilladelsesliste. At sammenligne dem er den hurtigste måde at finde ud af, hvilken tunnelen faktisk blokerer. Intet i login-outputtet angiver, hvilken af de tre der fejlede.

Tre værter, én loginhistorie

Web-loginforløbet overdrager identitetstrinnet til en browser, og den browser er ofte på din bærbare, mens CLI'en sidder på en fjern udviklingsvært eller i en container. Den bærbare har VPN-klienten, fjernværten har hvad platformteamet gav den, og ingen af de to opsætninger dækker automatisk den anden. Et VPN-ikon i statuslinjen siger intet om en vært, der aldrig har kørt klienten.

Efter login laver CLI'en sine egne API-anmodninger fra hvor processen nu lever. De anmodninger kræver DNS, routing, TLS-tillid og klientgodkendelse på org-siden, hvilket er fire separate kontroller, der hver kan fejle alene. En browser, der loggede ind flot, fortæller dig intet om nogen af dem.

Hold begge halvdele på én tidslinje, men bedøm dem hver for sig. Så kan én sag sige, hvilken halvdel der brød, uden at det bliver en diskussion om ejerskab.

Tag org-posteringen fra org'en, ikke fra hukommelsen

Webforløbet tager en instans-URL og gemmer resultatet under et alias, og begge værdier bør komme fra org-ejeren frem for fra en kollegas terminalhistorik. En sandbox-vært kopieret fra en gammel sag er en almindelig årsag til et login, der godkender mod den forkerte org og derefter fejler hver forespørgsel.

Brug den form, som det installerede plugin dokumenterer, med din egen godkendte vært og alias. Den dokumentation er reference for de flag, der ændrede sig mellem sfdx og den nuværende CLI.

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

Værtsnavnet og aliaset ovenfor er eksempler, ikke standardværdier, du bør kopiere. Gennemfør de normale browseridentitets- og MFA-trin i stedet for at scripte dig uden om dem, og læg aldrig en adgangskode, en sessionsidentifikator eller et autentificeringsfrø i en shell-kommando for at springe prompten over.

Hvad den cachede godkendelse beviser

Et alias, der optræder på den lokale godkendelsesliste, beviser, at et login engang lykkedes på den maskine. Listen læses fra lokal lagring og kontakter ikke org'en for at bekræfte, at tokenet stadig virker, så en sundt udseende post og et afvist API-kald kan begge være sande. Behandl cachen som en registrering af fortiden, ikke som en test af live-forbindelsen. En cachekontrol besvarer et supportspørgsmål, men den lukker aldrig en undersøgelse af forbindelsen.

Den samme forskel gælder browsersessionen. En fane, der stadig viser org'en, betyder ikke, at CLI'ens gemte token matcher den nuværende politik, fordi tokenlevetid, IP-begrænsninger og klientapp-regler håndhæves ved API-grænsen.

Læs den lokale post, før du sletter den, da aliaset og org-værten er de to fakta, support vil spørge om. At fjerne et alias er reversibelt, men at fjerne det forkerte midt i en hændelse tilføjer bare et andet problem.

Hvor API-anmodningen faktisk afvises

Følg én anmodning hele vejen og noter, hvilken komponent der svarer. En TLS-fejl navngiver et andet problem end en 403, som navngiver et andet problem end en timeout, og en timeout er den eneste af de tre, der peger på tunnelen som den første mistænkte. At læse fejlklassen før beskeden sparer en masse gætteri. Skriv klassen ned, før du kører noget igen.

Kildeadressebegrænsninger er det tilfælde, der giver et login, der virker, og en forespørgsel, der ikke gør, fordi browserforløbet og API-kaldet kan forlade systemet gennem forskellige adresser. At rette det med en bredere tilladelsesliste er org-ejerens beslutning, ikke en bekvemmelighed, og det bør være det mindste interval, der dækker værten.

Registrér den fejlende kommando, aliaset, udførelsesværten og tidsstemplet, og hold tokenet ude af alt, hvad du indsætter i sagen. Det fireslinjede resumé er, hvad org-ejeren skal bruge for at kontrollere sin side.

Kontrollér forløbet fra den vært, der skal bruge det

Test fra den maskine, der skal køre arbejdsbyrden. Et login, der er verificeret på din bærbare, siger intet om en build-agent i en anden netværkszone, og forskellen er præcis det, du prøver at finde.

Brug en uskadelig godkendt læsning til kontrollen, og behold den første fejl, hvis den fejler.

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

Når login lykkes, men forespørgslen fejler, er de resterende kandidater DNS, routing, TLS-aflytning og klientpolitik på org-siden, og hver har sin egen ejer. Når selve login fejler, er browseren og CLI'en sandsynligvis ikke på samme vært, og rettelsen hører til opsætningen mellem dem snarere end til tunnelen. Automatisering får én regel mere: et uovervåget job kræver et godkendt certifikatbaseret login, fordi en cachet interaktiv session kopieret til en worker ikke er et identitetsdesign.