Eniro al Salesforce CLI tra VPN: CLI, retumilo kaj API-gastiganto

Malsukcesoj de eniro al Salesforce CLI estas raportataj kiel unu problemo kaj kutime estas tri. La CLI-procezo funkcias ie, la retumilo, kiu finplenumas la retan fluon, funkcias ie, kaj la posta API-voko funkcias ie, kaj tiuj tri lokoj ne devas kunhavi itineron, solvilon aŭ permesliston. Kompari ilin estas la plej rapida maniero ekscii, kiun el ili la tunelo fakte blokas. Nenio en la eligo de la eniro nomas, kiu el la tri malsukcesis.

Tri gastigantoj, unu enira rakonto

La reta enira fluo transdonas la identecpaŝon al retumilo, kaj tiu retumilo ofte estas sur via tekokomputilo dum la CLI sidas sur fora evoluiga gastiganto aŭ en ujo. La tekokomputilo havas la VPN-klienton, la fora gastiganto havas tion, kion donis al ĝi la platforma teamo, kaj neniu el la du aranĝoj aŭtomate kovras la alian. VPN-ikono en la statobreto diras nenion pri gastiganto, kiu neniam ruligis la klienton.

Post la eniro, la CLI faras siajn proprajn API-petojn de kie ajn la procezo vivas. Tiuj petoj bezonas DNS, itineradon, TLS-fidon kaj klientan rajtigon ĉe la organiza flanko, kiuj estas kvar apartaj kontroloj kaj ĉiu povas malsukcesi memstare. Retumilo, kiu bele ensalutis, diras al vi nenion pri iu ajn el ili.

Tenu ambaŭ duonojn en unu templinio, sed pritaksu ilin aparte. Tiam unu bileto povas diri, kiu duono rompiĝis, sen igi tion disputo pri posedo.

Prenu la organizan enskribon de la organizo, ne de la memoro

La reta fluo prenas URL-on de la instanco kaj konservas la rezulton sub kaŝnomo, kaj ambaŭ valoroj venigu de la organiza posedanto anstataŭ el la terminala historio de kolego. Gastiganto de sablujo kopiita el malnova bileto estas ofta kaŭzo de eniro, kiu aŭtentikigas kontraŭ la malĝusta organizo kaj poste malsukcesas ĉe ĉiu demando.

Uzu la formon, kiun dokumentas la instalita kromaĵo, kun via propra aprobita gastiganto kaj kaŝnomo. Tiu dokumentado estas la referenco por flagoj, kiuj ŝanĝiĝis inter sfdx kaj la nuna CLI.

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

La gastigantnomo kaj kaŝnomo supre estas ekzemploj, ne defaŭltoj, kiujn vi kopiu. Plenumu la normalajn retumilajn identec-paŝojn kaj MFA anstataŭ ĉirkaŭskripti ilin, kaj neniam metu pasvorton, seanco-identigilon aŭ aŭtentikigan semon en ŝelan komandon por preterpasi la inviton.

Kion pruvas la kaŝmemorigita rajtigo

Kaŝnomo aperanta en la loka rajtiga listo pruvas, ke eniro iam sukcesis sur tiu maŝino. La listo estas legata el loka konservejo kaj ne kontaktas la organizon por konfirmi, ke la ĵetono ankoraŭ funkcias, do sanaspekta enskribo kaj rifuzita API-voko povas ambaŭ esti veraj. Traktu la kaŝmemoron kiel registron de la pasinteco, ne kiel vivan konektecan teston. Kaŝmemora kontrolo respondas al subtena demando, sed ĝi neniam fermas konektecan esploron.

La sama distingo validas por la retumila seanco. Langeto, kiu ankoraŭ montras la organizon, ne signifas, ke la konservita ĵetono de la CLI kongruas kun la nuna politiko, ĉar ĵetona vivdaŭro, IP-limigoj kaj reguloj de klientaj aplikaĵoj estas devigataj ĉe la API-limo.

Legu la lokan registron antaŭ ol forigi ĝin, ĉar la kaŝnomo kaj la organiza gastiganto estas la du faktoj, kiujn subteno petos. Forigi kaŝnomon estas renversebla, sed forigi la malĝustan meze de okazaĵo nur aldonas duan problemon.

Kie la API-peto fakte estas rifuzata

Sekvu unu peton de komenco ĝis fino kaj notu, kiu komponanto respondas. TLS-malsukceso nomas alian problemon ol 403, kiu nomas alian problemon ol tempolimo, kaj tempolimo estas la sola el la tri, kiu montras al la tunelo kiel unua suspektato. Legi la erarklason antaŭ la mesaĝo ŝparas multan konjektadon. Skribu la klason antaŭ ol relanĉi ion ajn.

Limigoj de fontadreso estas la kazo, kiu produktas eniron, kiu funkcias, kaj demandon, kiu ne, ĉar la retumila fluo kaj la API-voko povas eliri tra malsamaj adresoj. Ripari tion per pli vasta permeslisto estas decido de la organiza posedanto, ne oportuneco, kaj ĝi estu la plej malgranda gamo, kiu kovras la gastiganton.

Kaptu la malsukcesan komandon, la kaŝnomon, la plenumgastiganton kaj la tempostampon, kaj lasu la ĵetonon ekster ĉio, kion vi algluas en la bileton. Tiu kvar-linia resumo estas tio, kion la organiza posedanto bezonas por kontroli sian flankon.

Kontrolu la fluon de la gastiganto, kiu uzos ĝin

Testu de la maŝino, kiu plenumos la laborŝarĝon. Eniro kontrolita sur via tekokomputilo diras nenion pri konstruagento en alia reta zono, kaj la diferenco estas ĝuste tio, kion vi provas trovi.

Uzu sendanĝeran rajtigitan legadon por la kontrolo, kaj konservu la unuan eraron, se ĝi malsukcesos.

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

Kiam la eniro sukcesas sed la demando malsukcesas, la restantaj kandidatoj estas DNS, itinerado, TLS-interkaptado kaj klienta politiko ĉe la organiza flanko, kaj ĉiu havas sian propran posedanton. Kiam la eniro mem malsukcesas, la retumilo kaj la CLI verŝajne ne estas sur la sama gastiganto, kaj la korekto apartenas al la aranĝo inter ili prefere ol al la tunelo. Aŭtomatigo ricevas unu plian regulon: neprizorita tasko bezonas aprobitan atestilbazitan eniron, ĉar kaŝmemorigita interaga seanco kopiita al laboranto ne estas identecdezajno.