Zlyhania prihlásenia do Salesforce CLI sa hlásia ako jeden problém a zvyčajne sú tri. Proces CLI beží niekde, prehliadač, ktorý dokončuje webový tok, beží niekde, a neskoršie volanie API beží niekde, a tieto tri miesta nemusia zdieľať trasu, resolver ani zoznam povolených. Porovnať ich je najrýchlejší spôsob, ako zistiť, ktoré z nich tunel skutočne blokuje. Nič vo výstupe prihlásenia neuvádza, ktoré z troch zlyhalo.

Traja hostitelia, jeden príbeh prihlásenia

Webový tok prihlásenia odovzdáva krok identity prehliadaču a ten prehliadač je často na notebooku, zatiaľ čo CLI sedí na vzdialenom vývojovom hostiteľovi alebo v kontajneri. Notebook má klienta VPN, vzdialený hostiteľ má to, čo mu dal tím platformy, a ani jedno usporiadanie automaticky nepokrýva druhé. Ikona VPN v stavovom riadku nehovorí nič o hostiteľovi, ktorý klienta nikdy nespustil.

Po prihlásení robí CLI vlastné požiadavky na API odtiaľ, kde proces žije. Tieto požiadavky potrebujú DNS, smerovanie, dôveru v TLS a autorizáciu klienta na strane orgu, čo sú štyri samostatné kontroly a každá môže zlyhať sama. Prehliadač, ktorý sa krásne prihlásil, vám o žiadnej z nich nič nepovie.

Držte obe polovice na jednej časovej osi, ale hodnotte ich oddelene. Potom jeden tiket môže povedať, ktorá polovica sa pokazila, bez toho aby sa z toho stal spor o vlastníctvo.

Údaj o orge vezmite od orgu, nie z pamäti

Webový tok vezme URL inštancie a uloží výsledok pod alias a obe hodnoty by mali pochádzať od vlastníka orgu, nie z histórie terminálu kolegu. Hostiteľ sandboxu skopírovaný zo starého tiketu je častou príčinou prihlásenia, ktoré sa autentizuje proti nesprávnemu orgu a potom zlyhá pri každom dopyte.

Použite podobu, ktorú dokumentuje nainštalovaný plugin, s vlastným schváleným hostiteľom a aliasom. Tá dokumentácia je referenciou pre prepínače, ktoré sa medzi sfdx a súčasným CLI zmenili.

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

Názov hostiteľa a alias vyššie sú príklady, nie predvolené hodnoty, ktoré by ste mali kopírovať. Dokončite bežné kroky identity v prehliadači a MFA, namiesto toho aby ste ich obchádzali skriptom, a nikdy nedávajte heslo, identifikátor relácie ani seed autentifikátora do shellového príkazu, aby ste výzvu preskočili.

Čo uložená autorizácia dokazuje

Alias, ktorý sa objaví v miestnom zozname autorizácií, dokazuje, že prihlásenie na tom stroji raz uspelo. Zoznam sa číta z miestneho úložiska a nekontaktuje org, aby potvrdil, že token stále funguje, takže zdravo vyzerajúci záznam a odmietnuté volanie API môžu byť pravdivé zároveň. Berte vyrovnávaciu pamäť ako záznam minulosti, nie ako test živého pripojenia. Kontrola vyrovnávacej pamäte odpovedá na otázku podpory, ale vyšetrovanie pripojenia nikdy neuzavrie.

Rovnaký rozdiel platí pre reláciu prehliadača. Karta, ktorá stále zobrazuje org, neznamená, že uložený token CLI zodpovedá súčasnej politike, pretože životnosť tokenu, obmedzenia IP a pravidlá klientskej aplikácie sa presadzujú na hranici API.

Prečítajte miestny záznam, skôr než ho vymažete, pretože alias a hostiteľ orgu sú dva údaje, ktoré si podpora vyžiada. Odstránenie aliasu je vratné, ale odstránenie nesprávneho uprostred incidentu len pridá druhý problém.

Kde sa požiadavka na API skutočne odmieta

Sledujte jednu požiadavku od začiatku do konca a všimnite si, ktorá komponenta odpovedá. Zlyhanie TLS pomenúva iný problém ako 403, ktoré pomenúva iný problém ako časový limit, a časový limit je jediný z troch, ktorý ukazuje na tunel ako prvého podozrivého. Čítanie triedy chyby pred správou ušetrí veľa hádania. Zapíšte triedu, skôr než čokoľvek znova spustíte.

Obmedzenia zdrojovej adresy sú prípad, ktorý dáva prihlásenie, ktoré funguje, a dopyt, ktorý nie, pretože webový tok a volanie API môžu vychádzať z rôznych adries. Opraviť to širším zoznamom povolených je rozhodnutie vlastníka orgu, nie pohodlie, a mal by to byť najmenší rozsah, ktorý hostiteľa pokrýva.

Zachyťte zlyhávajúci príkaz, alias, hostiteľa spustenia a časovú pečiatku a token nechajte mimo všetkého, čo vložíte do tiketu. Tento štvorriadkový súhrn potrebuje vlastník orgu, aby skontroloval svoju stranu.

Overte tok z hostiteľa, ktorý ho bude používať

Testujte zo stroja, ktorý bude úlohu spúšťať. Prihlásenie overené na vašom notebooku nič nehovorí o build agentovi v inej sieťovej zóne a rozdiel je presne to, čo sa snažíte nájsť.

Na kontrolu použite neškodné autorizované čítanie a ak zlyhá, prvú chybu si ponechajte.

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

Keď prihlásenie uspeje, ale dopyt zlyhá, zostávajúcimi kandidátmi sú DNS, smerovanie, odpočúvanie TLS a klientska politika na strane orgu a každý má svojho vlastníka. Keď zlyhá samotné prihlásenie, prehliadač a CLI pravdepodobne nie sú na tom istom hostiteľovi a oprava patrí usporiadaniu medzi nimi, nie tunelu. Automatizácia dostáva ešte jedno pravidlo: neobsluhovaná úloha potrebuje schválené prihlásenie založené na certifikáte, pretože uložená interaktívna relácia skopírovaná na workera nie je návrh identity.

Súvisiace články