Пријава на Salesforce CLI преко VPN-а: CLI, прегледач и API хост

Грешке при пријави на Salesforce CLI пријављују се као један проблем, а обично су три. CLI процес ради негде, прегледач који завршава веб ток ради негде, а каснији API позив ради негде, и та три места не морају да деле руту, resolver или листу дозвола. Њихово поређење је најбржи начин да откријете који од њих тунел заиста блокира. Ништа у излазу пријаве не наводи који је од три неуспео.

Три хоста, једна прича о пријави

Веб ток пријаве предаје корак идентитета прегледачу, а тај прегледач је често на преносном рачунару док CLI седи на удаљеном хосту за развој или у контејнеру. Преносни рачунар има VPN клијент, удаљени хост има оно што му је дао тим за платформу, и ниједна од те две поставке аутоматски не покрива другу. Икона VPN-а у траци стања не говори ништа о хосту који никада није покренуо клијент.

Након пријаве, CLI прави сопствене API захтеве са места на ком процес живи. Ти захтеви траже DNS, рутирање, TLS поверење и клијентску ауторизацију са org стране, што су четири одвојене провере и свака може да не успе сама. Прегледач који се лепо пријавио не говори вам ништа ни о једној од њих.

Држите обе половине на једној временској линији, али их оцењујте одвојено. Тада један тикет може да каже која половина се сломила без тога да то постане расправа о власништву.

Узмите запис org-а од org-а, не из памћења

Веб ток узима URL инстанце и чува резултат под псеудонимом, и обе вредности треба да дођу од власника org-а, а не из историје терминала колеге. Хост sandbox-а копиран са старог тикета чест је узрок пријаве која се аутентификује на погрешан org и затим не успева при сваком упиту.

Користите облик који документује инсталирани додатак, са својим одобреним хостом и псеудонимом. Та документација је референца за заставице које су се промениле између sfdx и тренутног CLI-а.

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

Име хоста и псеудоним горе су примери, а не подразумеване вредности које треба да копирате. Завршите уобичајене кораке идентитета у прегледачу и MFA, уместо да их заобилазите скриптом, и никада не стављајте лозинку, идентификатор сесије или семе аутентификатора у shell команду да бисте прескочили захтев.

Шта доказује кеширана ауторизација

Псеудоним који се појави у локалној листи ауторизација доказује да је пријава једном успела на том рачунару. Листа се чита из локалног складишта и не контактира org да би потврдила да токен још ради, тако да здраво изгледајући запис и одбијен API позив могу истовремено да буду истинити. Третирајте кеш као запис о прошлости, а не као тест живе повезаности. Провера кеша одговара на питање подршке, али никада не затвара истрагу о повезаности.

Иста разлика важи и за сесију прегледача. Језичак који још приказује org не значи да сачувани токен CLI-а одговара тренутној политици, јер се животни век токена, IP ограничења и правила клијентске апликације спроводе на граници API-ја.

Прочитајте локални запис пре него што га избришете, јер су псеудоним и хост org-а те две чињенице које ће подршка тражити. Уклањање псеудонима је повратно, али уклањање погрешног усред инцидента само додаје други проблем.

Где се API захтев заиста одбија

Пратите један захтев од почетка до краја и забележите која компонента одговара. TLS неуспех именује други проблем од 403, који именује други проблем од истека времена, а истек времена је једини од три који указује на тунел као првог осумњиченог. Читање класе грешке пре поруке штеди много претпоставки. Запишите класу пре него што било шта поново покренете.

Ограничења изворне адресе су случај који даје пријаву која ради и упит који не ради, јер веб ток и API позив могу да изађу кроз различите адресе. Поправљање тога широм листом дозвола је одлука власника org-а, не погодност, и требало би да буде најмањи опсег који покрива хост.

Забележите команду која не успева, псеудоним, хост извршавања и временску ознаку, а токен оставите изван свега што залепите у тикет. Тај сажетак од четири реда је оно што власнику org-а треба да провери своју страну.

Проверите ток са хоста који ће га користити

Тестирајте са машине која ће извршавати радни терет. Пријава потврђена на вашем преносном рачунару не говори ништа о build агенту у другој мрежној зони, и разлика је управо оно што покушавате да пронађете.

За проверу користите безопасно одобрено читање, и ако не успе, задржите прву грешку.

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

Када пријава успе, али упит не успе, преостали кандидати су DNS, рутирање, TLS пресретање и клијентска политика са org стране, и сваки има свог власника. Када сама пријава не успе, прегледач и CLI вероватно нису на истом хосту, и поправка припада поставци између њих, а не тунелу. Аутоматизација добија још једно правило: посао без надзора захтева одобрену пријаву засновану на сертификату, јер кеширана интерактивна сесија копирана на радника није дизајн идентитета.