VPN аркылуу Salesforce CLI кирүү: 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 ээсине өз тарабын текшерүү үчүн керек.

Агымды аны колдоно турган хосттон текшериңиз

Жүктөмдү аткара турган машинадан сынаңыз. Ноутбукта текшерилген кирүү башка тармак аймагындагы 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 бир хостто эмес болушу ыктымал, жана оңдоо туннелге эмес, алардын ортосундагы жайгаштырууга тиешелүү. Автоматташтыруу дагы бир эреже алат: көзөмөлсүз ишке бекитилген сертификатка негизделген кирүү керек, анткени жумушчуга көчүрүлгөн кэштелген интерактивдүү сессия идентификация дизайны эмес.