Salesforce CLI sisselogimine VPN-i kaudu: CLI, brauser ja API-host

Salesforce CLI sisselogimise tõrkeid teatatakse ühe probleemina ja tavaliselt on neid kolm. CLI protsess töötab kuskil, veebivoo lõpule viiv brauser töötab kuskil ja hilisem API-kutse töötab kuskil, ning need kolm kohta ei pea jagama marsruuti, resolverit ega lubatud loendit. Nende võrdlemine on kiireim viis teada saada, millist neist tunnel tegelikult blokeerib. Miski sisselogimise väljundis ei nimeta, milline kolmest ebaõnnestus.

Kolm hosti, üks sisselogimislugu

Veebipõhine sisselogimisvoog annab identiteedisammu brauserile ja see brauser on sageli sinu sülearvutis, samal ajal kui CLI istub kaugel arendushostil või konteineris. Sülearvutis on VPN-klient, kauges hostis on see, mille platvormimeeskond talle andis, ja kumbki korraldus ei kata automaatselt teist. Olekuriba VPN-ikoon ei ütle midagi hosti kohta, mis ei ole kunagi klienti käivitanud.

Pärast sisselogimist teeb CLI oma API-päringud sealt, kus protsess elab. Need päringud vajavad DNS-i, marsruutimist, TLS-i usaldust ja kliendi autoriseerimist org-i poolel, mis on neli eraldi kontrolli ja igaüks võib iseseisvalt ebaõnnestuda. Brauser, mis logis ilusti sisse, ei ütle sulle neist ühegi kohta midagi.

Hoidke mõlemad pooled ühel ajateljel, kuid hinnake neid eraldi. Siis saab üks pilet öelda, milline pool katki läks, ilma et sellest saaks omandiõiguse vaidlus.

Võtke org-i kirje org-ilt, mitte mälust

Veebivoog võtab eksemplari URL-i ja salvestab tulemuse aliase alla ning mõlemad väärtused peaksid tulema org-i omanikult, mitte kolleegi terminaliajaloost. Vanast piletist kopeeritud sandbox-host on tavaline põhjus, miks sisselogimine autendib vale org-i vastu ja seejärel ebaõnnestub iga päring.

Kasutage kuju, mida paigaldatud plugin dokumenteerib, oma kinnitatud hosti ja aliasiga. See dokumentatsioon on viide lippudele, mis sfdx ja praeguse CLI vahel muutusid.

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

Ülaltoodud hostinimi ja alias on näited, mitte vaikeväärtused, mida peaksite kopeerima. Lõpetage tavalised brauseri identiteedi- ja MFA-sammud, selle asemel et neist skriptiga mööda minna, ja ärge kunagi pange parooli, sessiooni identifikaatorit ega autentija seemet kestakäsku, et viipa vahele jätta.

Mida vahemällu salvestatud autoriseerimine tõestab

Kohalikus autoriseerimisloendis ilmuv alias tõestab, et sisselogimine õnnestus kunagi selles masinas. Loendit loetakse kohalikust salvestusest ega võta org-iga ühendust, et kinnitada, kas token veel töötab, seega terve välimusega kirje ja tagasilükatud API-kutse võivad mõlemad olla tõesed. Käsitlege vahemälu mineviku kirjena, mitte reaalajas ühenduvuse testina. Vahemälu kontroll vastab tugiküsimusele, kuid ei sulge kunagi ühenduvuse uurimist.

Sama eristus kehtib brauseri sessiooni kohta. Vaheleht, mis näitab endiselt org-i, ei tähenda, et CLI salvestatud token vastab praegusele poliitikale, sest tokeni eluiga, IP-piirangud ja klientrakenduse reeglid kehtivad API piiril.

Lugege kohalikku kirjet enne selle kustutamist, sest alias ja org-i host on kaks fakti, mida tugi küsib. Aliase eemaldamine on pööratav, kuid vale aliase eemaldamine intsidendi keskel lisab lihtsalt teise probleemi.

Kus API-päring tegelikult tagasi lükatakse

Jälgige ühte päringut algusest lõpuni ja pange tähele, milline komponent vastab. TLS-i tõrge nimetab teistsugust probleemi kui 403, mis nimetab teistsugust probleemi kui aegumine, ja aegumine on ainus kolmest, mis osutab tunnelile kui esimesele kahtlusalusele. Veaklassi lugemine enne sõnumit säästab palju oletusi. Kirjutage klass üles enne, kui midagi uuesti käivitate.

Lähteaadressi piirangud on juhtum, mis annab sisselogimise, mis töötab, ja päringu, mis ei tööta, sest brauserivoog ja API-kutse võivad väljuda erinevatest aadressidest. Selle parandamine laiema lubatud loendiga on org-i omaniku otsus, mitte mugavus, ja see peaks olema väikseim vahemik, mis hosti katab.

Jäädvustage ebaõnnestuv käsk, alias, täitmishost ja ajatempel ning jätke token kõigest välja, mille piletisse kleepite. See neljarealine kokkuvõte on see, mida org-i omanik vajab oma poole kontrollimiseks.

Kontrollige voogu hostist, mis seda kasutama hakkab

Testige masinast, mis töökoormust hakkab käitama. Sülearvutis kontrollitud sisselogimine ei ütle midagi teises võrgutsoonis oleva build-agendi kohta ja erinevus on täpselt see, mida proovite leida.

Kasutage kontrolliks kahjutut autoriseeritud lugemist ja kui see ebaõnnestub, jätke esimene viga alles.

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

Kui sisselogimine õnnestub, kuid päring ebaõnnestub, on ülejäänud kandidaadid DNS, marsruutimine, TLS-i vaheltlõikamine ja kliendipoliitika org-i poolel ning igaühel on oma omanik. Kui sisselogimine ise ebaõnnestub, ei ole brauser ja CLI tõenäoliselt samas hostis ning parandus kuulub nendevahelise korralduse, mitte tunneli juurde. Automatiseerimine saab veel ühe reegli: järelevalveta töö vajab kinnitatud sertifikaadipõhist sisselogimist, sest töötajale kopeeritud vahemällu salvestatud interaktiivne sessioon ei ole identiteedi disain.