Přihlášení k Salesforce CLI přes VPN: CLI, prohlížeč a hostitel API

Selhání přihlášení k Salesforce CLI se hlásí jako jeden problém a obvykle jsou tři. Proces CLI běží někde, prohlížeč, který dokončuje webový tok, běží někde, a pozdější volání API běží někde, a tato tři místa nemusí sdílet trasu, resolver ani seznam povolených. Porovnat je je nejrychlejší způsob, jak zjistit, které z nich tunel skutečně blokuje. Nic ve výstupu přihlášení neuvádí, které ze tří selhalo.

Tři hostitelé, jeden příběh přihlášení

Webový tok přihlášení předává krok identity prohlížeči a ten prohlížeč je často na vašem notebooku, zatímco CLI sedí na vzdáleném vývojovém hostiteli nebo v kontejneru. Notebook má klienta VPN, vzdálený hostitel má to, co mu dal platformní tým, a ani jedno uspořádání automaticky nepokrývá druhé. Ikona VPN ve stavovém řádku nic neříká o hostiteli, který klienta nikdy nespustil.

Po přihlášení dělá CLI vlastní požadavky na API odkudkoli, kde proces žije. Tyto požadavky potřebují DNS, směrování, důvěru v TLS a autorizaci klienta na straně orgu, což jsou čtyři samostatné kontroly a každá může selhat sama. Prohlížeč, který se krásně přihlásil, vám o žádné z nich nic neřekne.

Držte obě poloviny na jedné časové ose, ale hodnoťte je odděleně. Jeden tiket pak může říct, která polovina se rozbila, aniž by se z toho stal spor o vlastnictví.

Údaj o orgu berte od orgu, ne z paměti

Webový tok vezme URL instance a uloží výsledek pod alias a obě hodnoty by měly pocházet od vlastníka orgu, ne z historie terminálu kolegy. Hostitel sandboxu zkopírovaný ze starého tiketu je častou příčinou přihlášení, které se autentizuje proti špatnému orgu a potom selže u každého dotazu.

Použijte podobu, kterou dokumentuje nainstalovaný plugin, s vlastním schváleným hostitelem a aliasem. Ta dokumentace je referencí pro přepínače, které se mezi sfdx a současným CLI změnily.

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

Název hostitele a alias výše jsou příklady, ne výchozí hodnoty, které byste měli kopírovat. Dokončete běžné kroky identity v prohlížeči a MFA, místo abyste je obcházeli skriptem, a nikdy nedávejte heslo, identifikátor relace ani seed autentikátoru do shellového příkazu, abyste výzvu přeskočili.

Co uložená autorizace dokazuje

Alias, který se objeví v místním seznamu autorizací, dokazuje, že přihlášení na tom stroji jednou uspělo. Seznam se čte z místního úložiště a nekontaktuje org, aby potvrdil, že token stále funguje, takže zdravě vypadající záznam a odmítnuté volání API mohou být pravdivé zároveň. Berte cache jako záznam minulosti, ne jako test živého připojení. Kontrola cache odpovídá na otázku podpory, ale vyšetřování připojení nikdy neuzavře.

Stejný rozdíl platí pro relaci prohlížeče. Karta, která stále zobrazuje org, neznamená, že uložený token CLI odpovídá současné politice, protože životnost tokenu, omezení IP a pravidla klientské aplikace se vynucují na hranici API.

Přečtěte místní záznam, než ho smažete, protože alias a hostitel orgu jsou dva údaje, které si podpora vyžádá. Odebrání aliasu je vratné, ale odebrání špatného uprostřed incidentu jen přidá druhý problém.

Kde je požadavek na API skutečně odmítnut

Sledujte jeden požadavek od začátku do konce a všimněte si, která komponenta odpovídá. Selhání TLS pojmenovává jiný problém než 403, které pojmenovává jiný problém než časový limit, a časový limit je jediný ze tří, který ukazuje na tunel jako prvního podezřelého. Čtení třídy chyby před zprávou ušetří mnoho hádání. Zapište třídu, než cokoli spustíte znovu.

Omezení zdrojové adresy jsou případ, který dává přihlášení, jež funguje, a dotaz, který ne, protože webový tok a volání API mohou vycházet z různých adres. Opravit to širším seznamem povolených je rozhodnutí vlastníka orgu, ne pohodlí, a měl by to být nejmenší rozsah, který hostitele pokrývá.

Zachyťte selhávající příkaz, alias, hostitele spuštění a časové razítko a token nechte mimo vše, co vložíte do tiketu. Tento čtyřřádkový souhrn potřebuje vlastník orgu, aby zkontroloval svou stranu.

Ověřte tok z hostitele, který jej bude používat

Testujte ze stroje, který bude úlohu spouštět. Přihlášení ověřené na vašem notebooku nic neříká o build agentovi v jiné síťové zóně a rozdíl je přesně to, co se snažíte najít.

Pro kontrolu použijte neškodné autorizované čtení a pokud selže, první chybu si ponechte.

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

Když přihlášení uspěje, ale dotaz selže, zbývajícími kandidáty jsou DNS, směrování, odposlech TLS a klientská politika na straně orgu a každý má svého vlastníka. Když selže samotné přihlášení, prohlížeč a CLI pravděpodobně nejsou na stejném hostiteli a oprava patří uspořádání mezi nimi, ne tunelu. Automatizace dostává ještě jedno pravidlo: neobsluhovaná úloha potřebuje schválené přihlášení založené na certifikátu, protože uložená interaktivní relace zkopírovaná na workera není návrh identity.