Pag-log in sa Salesforce CLI sa pamamagitan ng VPN: CLI, browser at API host

Ang mga pagkabigo sa pag-log in sa Salesforce CLI ay iniuulat bilang isang problema at kadalasan ay tatlo. Ang proseso ng CLI ay tumatakbo sa isang lugar, ang browser na kumukumpleto sa web flow ay tumatakbo sa isang lugar, at ang susunod na API call ay tumatakbo sa isang lugar, at ang tatlong lugar na iyon ay hindi kailangang magbahagi ng ruta, resolver o listahan ng pinapayagan. Ang paghahambing sa kanila ang pinakamabilis na paraan upang malaman kung alin ang talagang hinaharangan ng tunnel. Wala sa output ng pag-log in ang nagsasabi kung alin sa tatlo ang nabigo.

Tatlong host, isang kuwento ng pag-log in

Ang web login flow ay nagbibigay ng hakbang sa pagkakakilanlan sa isang browser, at ang browser na iyon ay madalas nasa laptop mo habang ang CLI ay nakaupo sa isang remote development host o sa isang container. Ang laptop ay may VPN client, ang remote host ay may ibinigay ng platform team, at wala sa dalawang setup ang awtomatikong sumasaklaw sa isa. Ang icon ng VPN sa status bar ay walang sinasabi tungkol sa isang host na hindi kailanman nagpatakbo ng client.

Pagkatapos ng pag-log in, ang CLI ay gumagawa ng sarili nitong mga API request mula sa kung saan nakatira ang proseso. Ang mga request na iyon ay nangangailangan ng DNS, routing, tiwala sa TLS at awtorisasyon ng client sa panig ng org, na apat na hiwalay na pagsusuri at bawat isa ay maaaring mabigo mag-isa. Ang browser na magandang nag-log in ay walang sinasabi sa iyo tungkol sa alinman sa kanila.

Panatilihin ang dalawang kalahati sa isang timeline, ngunit markahan ang mga ito nang hiwalay. Pagkatapos ay masasabi ng isang ticket kung aling kalahati ang nasira nang hindi ito nagiging pagtatalo tungkol sa pagmamay-ari.

Kunin ang entry ng org mula sa org, hindi mula sa memorya

Ang web flow ay kumukuha ng instance URL at iniimbak ang resulta sa ilalim ng isang alias, at ang parehong halaga ay dapat magmula sa may-ari ng org kaysa sa kasaysayan ng terminal ng isang kasamahan. Ang sandbox host na kinopya mula sa lumang ticket ay karaniwang dahilan ng pag-log in na nagpapatunay laban sa maling org at pagkatapos ay nabigo sa bawat query.

Gamitin ang anyo na dokumentado ng naka-install na plugin, kasama ang sarili mong aprubadong host at alias. Ang dokumentasyong iyon ang sanggunian para sa mga flag na nagbago sa pagitan ng sfdx at ng kasalukuyang CLI.

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

Ang hostname at alias sa itaas ay mga halimbawa, hindi mga default na dapat mong kopyahin. Kumpletuhin ang normal na browser identity at MFA steps sa halip na i-script ang pag-iwas sa mga ito, at huwag kailanman maglagay ng password, session identifier o authenticator seed sa isang shell command upang laktawan ang prompt.

Ano ang pinatutunayan ng naka-cache na awtorisasyon

Ang isang alias na lumilitaw sa lokal na listahan ng awtorisasyon ay nagpapatunay na ang pag-log in ay minsang nagtagumpay sa makinang iyon. Ang listahan ay binabasa mula sa lokal na imbakan at hindi nakikipag-ugnayan sa org upang kumpirmahin na gumagana pa ang token, kaya ang isang entry na mukhang malusog at isang tinanggihang API call ay maaaring parehong totoo. Tratuhin ang cache bilang talaan ng nakaraan, hindi bilang live na pagsubok ng koneksyon. Ang pagsusuri ng cache ay sumasagot sa isang tanong sa suporta, ngunit hindi kailanman nagsasara ng pagsisiyasat ng koneksyon.

Ang parehong pagkakaiba ay nalalapat sa session ng browser. Ang isang tab na nagpapakita pa rin ng org ay hindi nangangahulugang tumutugma ang naka-imbak na token ng CLI sa kasalukuyang patakaran, dahil ang tagal ng token, mga paghihigpit sa IP at mga panuntunan ng client app ay ipinapatupad sa hangganan ng API.

Basahin ang lokal na talaan bago mo ito burahin, dahil ang alias at ang org host ang dalawang katotohanang hihilingin ng suporta. Ang pag-alis ng alias ay maibabalik, ngunit ang pag-alis ng mali sa gitna ng isang insidente ay nagdaragdag lamang ng pangalawang problema.

Saan talaga tinatanggihan ang API request

Sundan ang isang request mula simula hanggang matapos at tandaan kung aling bahagi ang sumasagot. Ang TLS failure ay nagngangalan ng ibang problema kaysa sa 403, na nagngangalan ng ibang problema kaysa sa timeout, at ang timeout lang sa tatlo ang tumuturo sa tunnel bilang unang pinaghihinalaan. Ang pagbasa ng error class bago ang mensahe ay nakakatipid ng maraming hula. Isulat ang class bago magpatakbo muli ng anuman.

Ang mga paghihigpit sa source address ang kaso na nagdudulot ng pag-log in na gumagana at query na hindi, dahil ang browser flow at ang API call ay maaaring lumabas sa magkaibang address. Ang pag-aayos nito gamit ang mas malawak na listahan ng pinapayagan ay desisyon ng may-ari ng org, hindi kaginhawahan, at dapat itong ang pinakamaliit na saklaw na sumasaklaw sa host.

Itala ang command na nabigo, ang alias, ang execution host at ang timestamp, at iwanan ang token sa labas ng lahat ng idinidikit mo sa ticket. Ang apat na linyang buod na iyon ang kailangan ng may-ari ng org upang suriin ang kanyang panig.

Suriin ang flow mula sa host na gagamit nito

Subukan mula sa makina na magpapatakbo ng workload. Ang pag-log in na na-verify sa laptop mo ay walang sinasabi tungkol sa isang build agent sa ibang network zone, at ang pagkakaiba ay eksaktong sinusubukan mong hanapin.

Gumamit ng walang pinsalang awtorisadong pagbasa para sa pagsusuri, at kung mabigo, itago ang unang error.

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

Kapag nagtagumpay ang pag-log in ngunit nabigo ang query, ang natitirang mga kandidato ay DNS, routing, TLS interception at client policy sa panig ng org, at bawat isa ay may sariling may-ari. Kapag ang pag-log in mismo ang nabigo, ang browser at ang CLI ay malamang na wala sa parehong host, at ang pag-aayos ay kabilang sa setup sa pagitan nila at hindi sa tunnel. Ang automation ay makakakuha ng isa pang tuntunin: ang isang trabahong walang pangangasiwa ay nangangailangan ng aprubadong pag-log in na batay sa sertipiko, dahil ang naka-cache na interactive na session na kinopya sa isang worker ay hindi isang disenyo ng pagkakakilanlan.