Salesforce CLI-login via een VPN: CLI, browser en API-host

Fouten bij het inloggen op Salesforce CLI worden als één probleem gemeld en zijn meestal drie. Het CLI-proces draait ergens, de browser die de webflow afrondt draait ergens, en de latere API-aanroep draait ergens, en die drie plekken hoeven geen route, resolver of allowlist te delen. Ze vergelijken is de snelste manier om erachter te komen welke de tunnel echt blokkeert. Niets in de login-uitvoer noemt welke van de drie is mislukt.

Drie hosts, één loginverhaal

De web-loginflow geeft de identiteitsstap aan een browser, en die browser staat vaak op je laptop terwijl de CLI op een externe ontwikkelhost of in een container zit. De laptop heeft de VPN-client, de externe host heeft wat het platformteam hem gaf, en geen van beide opstellingen dekt automatisch de andere. Een VPN-pictogram in de statusbalk zegt niets over een host die de client nooit heeft gestart.

Na het inloggen doet de CLI zijn eigen API-aanroepen vanaf waar het proces leeft. Die aanroepen hebben DNS, routing, TLS-vertrouwen en clientautorisatie aan de org-kant nodig, dat zijn vier afzonderlijke controles en elk kan op zichzelf mislukken. Een browser die prachtig is ingelogd, vertelt je niets over een van hen.

Houd beide helften op één tijdlijn, maar beoordeel ze apart. Dan kan één ticket zeggen welke helft brak zonder er een discussie over eigenaarschap van te maken.

Neem de org-regel van de org, niet uit het geheugen

De webflow neemt een instantie-URL en slaat het resultaat op onder een alias, en beide waarden moeten van de orgeigenaar komen in plaats van uit de terminalgeschiedenis van een collega. Een sandbox-host die uit een oud ticket is gekopieerd is een veelvoorkomende oorzaak van een login die tegen de verkeerde org authenticeert en daarna elke query laat mislukken.

Gebruik de vorm die de geïnstalleerde plugin documenteert, met je eigen goedgekeurde host en alias. Die documentatie is de referentie voor flags die tussen sfdx en de huidige CLI zijn veranderd.

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

De hostnaam en alias hierboven zijn voorbeelden, geen standaardwaarden die je moet kopiëren. Rond de normale browseridentiteits- en MFA-stappen af in plaats van ze met een script te omzeilen, en zet nooit een wachtwoord, sessie-identificatie of authenticator-seed in een shellcommando om de prompt over te slaan.

Wat de gecachte autorisatie bewijst

Een alias die in de lokale autorisatielijst staat, bewijst dat een login ooit op die machine is geslaagd. De lijst wordt uit lokale opslag gelezen en neemt geen contact op met de org om te bevestigen dat het token nog werkt, dus een gezond uitziende vermelding en een geweigerde API-aanroep kunnen allebei waar zijn. Behandel de cache als een verslag van het verleden, niet als een live connectiviteitstest. Een cachecontrole beantwoordt een supportvraag, maar sluit nooit een connectiviteitsonderzoek af.

Hetzelfde onderscheid geldt voor de browsersessie. Een tabblad dat de org nog toont, betekent niet dat het opgeslagen token van de CLI bij het huidige beleid past, omdat tokenlevensduur, IP-beperkingen en clientapp-regels bij de API-grens worden afgedwongen.

Lees de lokale vermelding voordat je hem verwijdert, want de alias en de org-host zijn de twee feiten die support zal vragen. Een alias verwijderen is omkeerbaar, maar de verkeerde verwijderen midden in een incident voegt alleen een tweede probleem toe.

Waar de API-aanroep echt wordt geweigerd

Volg één aanroep van begin tot eind en noteer welk onderdeel antwoordt. Een TLS-fout noemt een ander probleem dan een 403, die een ander probleem noemt dan een time-out, en een time-out is de enige van de drie die de tunnel als eerste verdachte aanwijst. De foutklasse lezen vóór het bericht bespaart veel giswerk. Schrijf de klasse op voordat je iets opnieuw uitvoert.

Beperkingen op bronadressen zijn het geval dat een login oplevert die werkt en een query die niet werkt, omdat de browserflow en de API-aanroep via verschillende adressen naar buiten kunnen gaan. Dat oplossen met een bredere allowlist is een beslissing van de orgeigenaar, geen gemak, en het moet het kleinste bereik zijn dat de host dekt.

Leg het mislukkende commando, de alias, de uitvoeringshost en de tijdstempel vast, en laat het token weg uit alles wat je in het ticket plakt. Die samenvatting van vier regels is wat de orgeigenaar nodig heeft om zijn kant te controleren.

Controleer de flow vanaf de host die hem gaat gebruiken

Test vanaf de machine die de workload gaat draaien. Een login die op je laptop is geverifieerd zegt niets over een buildagent in een andere netwerkzone, en het verschil is precies wat je probeert te vinden.

Gebruik een onschadelijke geautoriseerde leesactie voor de controle, en bewaar de eerste fout als die mislukt.

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

Als de login slaagt maar de query mislukt, zijn de overgebleven kandidaten DNS, routing, TLS-onderschepping en clientbeleid aan de org-kant, en elk heeft zijn eigen eigenaar. Als de login zelf mislukt, staan de browser en de CLI waarschijnlijk niet op dezelfde host, en de oplossing hoort bij de opstelling tussen hen in plaats van bij de tunnel. Automatisering krijgt nog een regel: een onbeheerde taak heeft een goedgekeurde op certificaat gebaseerde login nodig, want een gecachte interactieve sessie die naar een worker is gekopieerd is geen identiteitsontwerp.