Влизане в Salesforce CLI през VPN: CLI, браузър и хост за API

Провалите при влизане в Salesforce CLI се докладват като един проблем, а обикновено са три. Процесът CLI работи някъде, браузърът, който завършва уеб потока, работи някъде, и последващото извикване на API работи някъде, и тези три места не са длъжни да споделят маршрут, резолвер или списък с разрешени адреси. Сравняването им е най-бързият начин да разберете кое от тях тунелът всъщност блокира. Нищо в изхода от влизането не посочва кое от трите се е провалило.

Три хоста, една история за влизане

Уеб потокът за влизане предава стъпката за идентичност на браузър и този браузър често е на вашия лаптоп, докато CLI седи на отдалечен хост за разработка или в контейнер. Лаптопът има VPN клиент, отдалеченият хост има каквото екипът на платформата му е дал, и нито една от двете подредби автоматично не покрива другата. Икона за VPN в лентата за състояние не казва нищо за хост, който никога не е стартирал клиента.

След влизането CLI прави собствени заявки към API от мястото, където живее процесът. Тези заявки се нуждаят от DNS, маршрутизация, доверие в TLS и клиентска оторизация от страна на организацията, които са четири отделни проверки и всяка може да се провали сама. Браузър, който се е вписал прекрасно, не ви казва нищо за нито една от тях.

Дръжте двете половини в една времева линия, но ги оценявайте поотделно. Тогава един тикет може да каже коя половина се е счупила, без да го превръща в спор за собственост.

Вземете записа за организацията от организацията, не от паметта

Уеб потокът взема URL на инстанция и съхранява резултата под псевдоним и двете стойности трябва да идват от собственика на организацията, а не от историята на терминала на колега. Хост за sandbox, копиран от стар тикет, е честа причина за влизане, което се удостоверява срещу грешната организация и после проваля всяка заявка.

Използвайте формата, която документира инсталираният плъгин, със свой одобрен хост и псевдоним. Тази документация е справката за флаговете, които са се променили между 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 команда, за да прескочите подканата.

Какво доказва кешираното разрешение

Псевдоним, който се появява в локалния списък за удостоверяване, доказва, че влизане някога е успяло на тази машина. Списъкът се чете от локално хранилище и не се свързва с организацията, за да потвърди, че токенът още работи, така че здравословно изглеждащ запис и отхвърлена заявка към API могат да бъдат верни едновременно. Отнасяйте се към кеша като запис за миналото, а не като тест на жива връзка. Проверката на кеша отговаря на въпрос от поддръжката, но никога не приключва разследване на свързаността.

Същото разграничение важи за сесията на браузъра. Раздел, който още показва организацията, не означава, че запазеният токен на CLI отговаря на текущата политика, защото животът на токена, IP ограниченията и правилата за клиентското приложение се налагат на границата на API.

Прочетете локалния запис, преди да го изтриете, защото псевдонимът и хостът на организацията са двата факта, които поддръжката ще поиска. Премахването на псевдоним е обратимо, но премахването на грешния по средата на инцидент просто добавя втори проблем.

Къде заявката към API всъщност се отхвърля

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

Ограниченията по адрес на източника са случаят, който дава влизане, което работи, и заявка, която не работи, защото уеб потокът и заявката към API могат да излязат през различни адреси. Оправянето с по-широк списък с разрешени адреси е решение на собственика на организацията, не удобство, и трябва да е най-малкият диапазон, който покрива хоста.

Запишете неуспешната команда, псевдонима, хоста на изпълнение и времевия печат и оставете токена извън всичко, което поставяте в тикета. Това резюме от четири реда е нужно на собственика на организацията, за да провери своята страна.

Проверете потока от хоста, който ще го използва

Тествайте от машината, която ще изпълнява натоварването. Влизане, проверено на лаптопа ви, не казва нищо за агент за изграждане в друга мрежова зона и разликата е точно това, което се опитвате да откриете.

Използвайте безвредно разрешено четене за проверката и запазете първата грешка, ако се провали.

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

Когато влизането успее, а заявката се провали, останалите кандидати са DNS, маршрутизация, прихващане на TLS и клиентска политика от страна на организацията и всеки има свой собственик. Когато самото влизане се провали, браузърът и CLI вероятно не са на един и същ хост и поправката принадлежи на подредбата между тях, а не на тунела. Автоматизацията получава още едно правило: необслужвана задача се нуждае от одобрено влизане със сертификат, защото кеширана интерактивна сесия, копирана в работник, не е дизайн на идентичност.