Salesforce CLI-inloggning över en VPN: CLI, webbläsare och API-värd

Fel vid Salesforce CLI-inloggning rapporteras som ett problem och är oftast tre. CLI-processen kör någonstans, webbläsaren som slutför webbflödet kör någonstans, och det senare API-anropet kör någonstans, och de tre platserna behöver inte dela en rutt, en resolver eller en tillåtelselista. Att jämföra dem är det snabbaste sättet att ta reda på vilken tunneln faktiskt blockerar. Inget i inloggningsutdata säger vilken av de tre som misslyckades.

Tre värdar, en inloggningshistoria

Webbinloggningsflödet lämnar identitetssteget till en webbläsare, och den webbläsaren finns ofta på den bärbara datorn medan CLI:n sitter på en fjärransluten utvecklingsvärd eller i en container. Den bärbara har VPN-klienten, fjärrvärden har det plattformsteamet gav den, och ingen av de två ordningarna täcker automatiskt den andra. En VPN-ikon i statusfältet säger ingenting om en värd som aldrig körde klienten.

Efter inloggningen gör CLI:n sina egna API-anrop från där processen lever. De anropen behöver DNS, routning, TLS-förtroende och klientauktorisering på org-sidan, vilket är fyra separata kontroller och var och en kan misslyckas själv. En webbläsare som loggade in vackert säger ingenting om någon av dem.

Håll båda halvorna på en tidslinje, men bedöm dem separat. Då kan ett ärende säga vilken halva som gick sönder utan att det blir en diskussion om ägande.

Ta org-posten från org:en, inte från minnet

Webbflödet tar en instans-URL och lagrar resultatet under ett alias, och båda värdena bör komma från org-ägaren i stället för från en kollegas terminalhistorik. En sandbox-värd kopierad från ett gammalt ärende är en vanlig orsak till en inloggning som autentiserar mot fel org och sedan misslyckas på varje fråga.

Använd den form som det installerade tillägget dokumenterar, med din egen godkända värd och alias. Den dokumentationen är referensen för flaggor som ändrades mellan sfdx och nuvarande CLI.

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

Värdnamnet och aliaset ovan är exempel, inte standardvärden du bör kopiera. Slutför de vanliga webbläsaridentitets- och MFA-stegen i stället för att kringgå dem med ett skript, och lägg aldrig ett lösenord, en sessionsidentifierare eller ett autentiseringsfrö i ett skalkommando för att hoppa över prompten.

Vad den cachade auktoriseringen bevisar

Ett alias som visas i den lokala auktoriseringslistan bevisar att en inloggning en gång lyckades på den maskinen. Listan läses från lokal lagring och kontaktar inte org:en för att bekräfta att token fortfarande fungerar, så en frisk utseende post och ett avvisat API-anrop kan båda vara sanna. Behandla cachen som en registrering av det förflutna, inte som ett test av den levande anslutningen. En cachekontroll svarar på en supportfråga, men den stänger aldrig en anslutningsutredning.

Samma distinktion gäller webbläsarsessionen. En flik som fortfarande visar org:en betyder inte att CLI:ns sparade token matchar den nuvarande policyn, eftersom tokenlivslängd, IP-begränsningar och klientappregler tillämpas vid API-gränsen.

Läs den lokala posten innan du raderar den, eftersom aliaset och org-värden är de två fakta supporten kommer att fråga om. Att ta bort ett alias är reversibelt, men att ta bort det felaktiga mitt i en incident lägger bara till ett andra problem.

Var API-anropet faktiskt avvisas

Följ ett anrop från början till slut och notera vilken komponent som svarar. Ett TLS-fel namnger ett annat problem än en 403, som namnger ett annat problem än en timeout, och en timeout är den enda av de tre som pekar på tunneln som första misstänkta. Att läsa felklassen före meddelandet sparar mycket gissande. Skriv ned klassen innan du kör något igen.

Källadressbegränsningar är fallet som ger en inloggning som fungerar och en fråga som inte gör det, eftersom webbflödet och API-anropet kan gå ut genom olika adresser. Att åtgärda det med en bredare tillåtelselista är org-ägarens beslut, inte en bekvämlighet, och det bör vara det minsta intervallet som täcker värden.

Registrera kommandot som misslyckas, aliaset, körningsvärden och tidsstämpeln, och håll token utanför allt du klistrar in i ärendet. Den fyra raders sammanfattningen är vad org-ägaren behöver för att kontrollera sin sida.

Kontrollera flödet från den värd som ska använda det

Testa från maskinen som ska köra arbetsbelastningen. En inloggning som verifierats på din bärbara säger ingenting om en byggagent i en annan nätverkszon, och skillnaden är exakt det du försöker hitta.

Använd en ofarlig godkänd läsning för kontrollen, och behåll det första felet om den misslyckas.

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

När inloggningen lyckas men frågan misslyckas, är de återstående kandidaterna DNS, routning, TLS-avlyssning och klientpolicy på org-sidan, och var och en har sin egen ägare. När själva inloggningen misslyckas är webbläsaren och CLI:n förmodligen inte på samma värd, och rättelsen hör till ordningen mellan dem snarare än till tunneln. Automatisering får en regel till: ett obevakat jobb behöver en godkänd certifikatbaserad inloggning, eftersom en cachad interaktiv session kopierad till en worker inte är en identitetsdesign.