Најавување во Salesforce CLI преку VPN: CLI, прелистувач и API домаќин

Неуспесите при најавување во Salesforce CLI се пријавуваат како еден проблем, а обично се три. Процесот CLI работи некаде, прелистувачот што го завршува веб-текот работи некаде, и подоцнежниот API повик работи некаде, и тие три места не мора да делат рута, резолвер или список на дозволи. Нивното споредување е најбрзиот начин да откриете кое од нив тунелот навистина го блокира. Ништо во излезот од најавувањето не кажува кое од трите не успеало.

Три домаќини, една приказна за најавување

Веб-текот за најавување го предава чекорот за идентитет на прелистувач, и тој прелистувач често е на преносниот сметач додека 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, наместо да ги заобиколувате со скрипта, и никогаш не ставајте лозинка, идентификатор на сесија или семе на автентикатор во команда на школка за да го прескокнете барањето.

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

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

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

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

Каде API барањето навистина се одбива

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

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

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

Проверете го текот од домаќинот што ќе го користи

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

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

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 веројатно не се на истиот домаќин, и поправката им припаѓа на поставките помеѓу нив, а не на тунелот. Автоматизацијата добива уште едно правило: работа без надзор бара одобрено најавување засновано на сертификат, бидејќи кеширана интерактивна сесија копирана на работник не е дизајн на идентитет.