Уваход у 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, а не абыходзьце іх скрыптам, і ніколі не змяшчайце пароль, ідэнтыфікатар сеансу або зерне аўтэнтыфікатара ў камандзе абалонкі, каб прапусціць запыт.

Што даказвае кэшаваная аўтарызацыя

Псеўданім у лакальным спісе аўтарызацыі даказвае, што ўваход аднойчы ўдаўся на гэтай машыне. Спіс чытаецца з лакальнага сховішча і не звяртаецца да арганізацыі, каб пацвердзіць, што токен яшчэ працуе, таму здаровы запіс і адхілены выклік 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, верагодна, не на адным хосце, і выпраўленне належыць парадку паміж імі, а не тунелю. Аўтаматызацыя атрымлівае яшчэ адно правіла: непрыгледжаная задача патрабуе ўхваленага ўваходу на аснове сертыфіката, бо кэшаваны інтэрактыўны сеанс, скапіяваны ў працоўнік, — не дызайн ідэнтычнасці.