Salesforce CLI-ynloggen fia in VPN: CLI, browser en API-host

Flaters by Salesforce CLI-ynloggen wurde as ien probleem rapportearre en binne meastal trije. It CLI-proses rint earne, de browser dy't de webloop foltôget rint earne, en de lettere API-oprop rint earne, en dy trije plakken hoewe gjin rûte, in resolver of in talittingslist te dielen. Se fergelykje is de fluchste manier om út te finen hokker de tunnel eins blokket. Neat yn de útfier fan it ynloggen neamt hokker fan de trije mislearre is.

Trije hosts, ien ynlogferhaal

De webloop foar ynloggen jout de identiteitsstap oan in browser, en dy browser is faak op jo laptop wylst de CLI op in ôfstân ûntwikkelingshost of yn in kontener sit. De laptop hat de VPN-klant, de ôfstânshost hat wat it platfoarmteam him joech, en gjin fan beide regelingen dekt automatysk de oare. In VPN-ikoan yn 'e statusbalke seit neat oer in host dy't de klant nea rûn hat.

Nei it ynloggen docht de CLI syn eigen API-oafliedingen fan wêr't it proses libbet. Dy oanfragen hawwe DNS, routing, TLS-fertrouwen en kliïntautorisearring oan 'e org-kant nedich, dat binne fjouwer aparte kontrôles en elk kin op himsels mislearje. In browser dy't prachtich oanmeld is, fertelt jo neat oer ien fan har.

Hâld beide helten op ien tiidline, mar beoardielje se apart. Dan kin ien ticket sizze hokker helte brutsen is sûnder dat it in diskusje oer eigendom wurdt.

Nim de org-yngong by de org, net út it ûnthâld

De webloop nimt in ynstânsje-URL en bewarret it resultaat ûnder in alias, en beide wearden moatte by de org-eigenaar wei komme ynstee fan út 'e terminalhistoarje fan in kollega. In sandbox-host dy't fan in âld ticket kopiearre is, is in gewoane oarsaak fan in ynloggen dat tsjin de ferkearde org autentisearret en dan elke oanfrage mislearret.

Brûk de foarm dy't de ynstalleare plugin dokumintearret, mei jo eigen goedkarde host en alias. Dy dokumintaasje is de referinsje foar flaggen dy't tusken sfdx en de hjoeddeiske CLI feroare binne.

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

De hostnamme en alias hjirboppe binne foarbylden, net standertwearden dy't jo kopiearje moatte. Foltôgje de normale browseridentiteit- en MFA-stappen ynstee fan se mei in skript te omgean, en set nea in wachtwurd, sesje-identifikaasje of autentikaasjesied yn in shell-opdracht om de fraach oer te slaan.

Wat de cachede autorisaasje bewissiget

In alias dy't yn 'e lokale autorisaasjelist ferskynt, bewissiget dat in ynloggen ienris op dy masine slagge is. De list wurdt út lokale opslach lêzen en nimt gjin kontakt op mei de org om te befêstigjen dat it token noch wurket, dus in sûn útsjende yngong en in wegere API-oprop kinne beide wier wêze. Behannelje de cache as in ferslach fan it ferline, net as in live ferbiningstest. In cache-kontrôle beantwurdet in stipefraach, mar slút nea in ferbiningsûndersyk.

Deselde ûnderskied jildt foar de browsersesje. In ljepblêd dat de org noch sjen lit, betsjut net dat it bewarre token fan 'e CLI by it hjoeddeiske belied past, want tokenlibben, IP-beheiningen en regels foar kliïntapplikaasjes wurde by de API-grins hanthavene.

Lês it lokale ferslach foardat jo it wiskje, want de alias en de org-host binne de twa feiten dy't stipe freegje sil. In alias fuortsmite is weromdraaibaar, mar de ferkearde fuortsmite midden yn in ynsidint foegt allinnich in twadde probleem ta.

Wêr't de API-oaflieding eins wegere wurdt

Folgje ien oanfrage fan begjin oant ein en notearje hokker komponint antwurdet. In TLS-flater neamt in oar probleem as in 403, dy't in oar probleem neamt as in timeout, en in timeout is de iennichste fan de trije dy't de tunnel as earste fertochte oanwiist. It lêzen fan de flaterklasse foar it berjocht besparret in soad rieden. Skriuw de klasse op foardat jo wat wer rinne litte.

Beheiningen fan boarneadres binne it gefal dat in ynloggen jout dat wurket en in oanfrage dy't dat net docht, want de webloop en de API-oprop kinne troch ferskate adressen nei bûten gean. Dat reparearje mei in bredere talittingslist is in beslút fan de org-eigenaar, gjin gemak, en it moat it lytste berik wêze dat de host dekt.

Fêstlizze de mislearjende opdracht, de alias, de útfieringshost en it tiidstimpel, en hâld it token bûten alles wat jo yn it ticket plakke. Dat oersjoch fan fjouwer rigels is wat de org-eigenaar nedich hat om syn kant te kontrolearjen.

Kontrolearje de loop fan de host dy't it brûke sil

Test fan de masine dy't de wurklêst rinne sil. In ynloggen dat op jo laptop ferifiearre is, seit neat oer in build-agent yn in oare netwurkzone, en it ferskil is krekt wat jo besykje te finen.

Brûk in ûnskodlike goedkarde lêzing foar de kontrôle, en hâld de earste flater as it mislearret.

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

As it ynloggen slagget mar de oanfrage mislearret, binne de oerbleaune kandidaten DNS, routing, TLS-ûnderskepping en kliïntbelied oan 'e org-kant, en elk hat syn eigen eigenaar. As it ynloggen sels mislearret, binne de browser en de CLI wierskynlik net op deselde host, en de oplossing heart by de regeling tusken har ynstee fan by de tunnel. Automatisaasje krijt noch ien regel: in net-besjoen baan hat in goedkarde sertifikaat-basearre ynloggen nedich, want in cachede ynteraktive sesje dy't nei in worker kopiearre is, is gjin identiteitsûntwerp.