Kuingia Salesforce CLI kupitia VPN: CLI, kivinjari na mwenyeji wa API

Hitilafu za kuingia Salesforce CLI zinaripotiwa kama tatizo moja na kwa kawaida ni matatu. Mchakato wa CLI unafanya kazi mahali fulani, kivinjari kinachokamilisha mtiririko wa wavuti kinafanya kazi mahali fulani, na wito wa API unaofuata unafanya kazi mahali fulani, na maeneo hayo matatu hayahitaji kushiriki njia, kitatuzi au orodha ya kuruhusiwa. Kuyalinganisha ndiyo njia ya haraka zaidi ya kujua ni kipi handaki inazuia kweli. Hakuna chochote kwenye matokeo ya kuingia kinachosema ni kipi kati ya matatu kilishindikana.

Wenyeji watatu, hadithi moja ya kuingia

Mtiririko wa kuingia kwa wavuti unakabidhi hatua ya utambulisho kwa kivinjari, na kivinjari hicho mara nyingi kiko kwenye kompyuta yako mpito wakati CLI imekaa kwenye mwenyeji wa mbali wa maendeleo au kwenye kontena. Kompyuta mpito ina mteja wa VPN, mwenyeji wa mbali ana kile timu ya jukwaa ilimpa, na hakuna mpangilio wowote kati ya hayo mawili unaofunika mwingine kiotomatiki. Aikoni ya VPN kwenye upau wa hali haisemi chochote kuhusu mwenyeji ambao haukuwahi kuendesha mteja.

Baada ya kuingia, CLI hufanya maombi yake mwenyewe ya API kutoka mahali mchakato unaishi. Maombi hayo yanahitaji DNS, uelekezaji, imani ya TLS na idhini ya mteja kutoka upande wa org, ambayo ni ukaguzi nne tofauti na kila mmoja unaweza kushindikana peke yake. Kivinjari kilichoingia vizuri hakikuambii chochote kuhusu yoyote kati ya hayo.

Weka nusu zote mbili kwenye mstari mmoja wa muda, lakini zikadirie kwa tofauti. Hapo tiketi moja inaweza kusema ni nusu ipi iliyovunjika bila kuigeuza kuwa mjadala kuhusu umiliki.

Chukua ingizo la org kutoka kwa org, sio kutoka kwenye kumbukumbu

Mtiririko wa wavuti huchukua URL ya mfano na kuhifadhi matokeo chini ya jina la utani, na thamani zote mbili zinapaswa kutoka kwa mmiliki wa org badala ya historia ya terminal ya mwenzako. Mwenyeji wa sandbox aliyenakiliwa kutoka tiketi ya zamani ni sababu ya kawaida ya kuingia kunakothibitisha dhidi ya org isiyo sahihi na kisha kushindikana kwenye kila swali.

Tumia muundo unaoandikwa na programu-jalizi iliyosakinishwa, ukiwa na mwenyeji na jina la utani uliloidhinisha mwenyewe. Nyaraka hizo ni rejeleo la bendera zilizobadilika kati ya sfdx na CLI ya sasa.

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

Jina la mwenyeji na jina la utani hapo juu ni mifano, sio chaguo-msingi unapaswa kunakili. Kamilisha hatua za kawaida za utambulisho wa kivinjari na MFA badala ya kuzipita kwa hati, na kamwe usiweke nenosiri, kitambulisho cha kikao au mbegu ya kithibitishaji kwenye amri ya ganda ili kuruka ombi.

Idhini iliyohifadhiwa inathibitisha nini

Jina la utani linaloonekana kwenye orodha ya idhini ya ndani linathibitisha kwamba kuingia kulifanikiwa mara moja kwenye mashine hiyo. Orodha inasomwa kutoka hifadhi ya ndani na haiwasiliani na org kuthibitisha kwamba token bado inafanya kazi, kwa hiyo ingizo linaloonekana lenye afya na wito wa API uliokataliwa vinaweza kuwa kweli kwa wakati mmoja. Chukua akiba ya kumbukumbu kama rekodi ya zamani, sio kama jaribio la muunganisho wa moja kwa moja. Ukaguzi wa akiba hujibu swali la usaidizi, lakini kamwe haufungi uchunguzi wa muunganisho.

Tofauti hiyo hiyo inatumika kwa kikao cha kivinjari. Kichupo kinachoendelea kuonyesha org hakimaanishi token iliyohifadhiwa ya CLI inalingana na sera ya sasa, kwa sababu muda wa maisha ya token, vikwazo vya IP na kanuni za programu ya mteja hutekelezwa kwenye mpaka wa API.

Soma rekodi ya ndani kabla ya kuifuta, kwani jina la utani na mwenyeji wa org ni mambo mawili ambayo usaidizi utauliza. Kuondoa jina la utani kunaweza kurejeshwa, lakini kuondoa lile lisilo sahihi katikati ya tukio huongeza tatizo la pili tu.

Ambapo ombi la API linakataliwa kweli

Fuatilia ombi moja kutoka mwanzo hadi mwisho na uangalie ni sehemu ipi inayojibu. Kushindikana kwa TLS kunataja tatizo tofauti na 403, ambalo linataja tatizo tofauti na muda wa kumalizika, na muda wa kumalizika ndio pekee kati ya matatu unaoelekeza handaki kama mshukiwa wa kwanza. Kusoma darasa la hitilafu kabla ya ujumbe huokoa nadhani nyingi. Andika darasa kabla ya kuendesha kitu chochote tena.

Vikwazo vya anwani ya chanzo ndio kesi inayozalisha kuingia kunakofanya kazi na swali lisilofanya kazi, kwa sababu mtiririko wa kivinjari na wito wa API vinaweza kutoka kupitia anwani tofauti. Kurekebisha hilo kwa orodha pana ya kuruhusiwa ni uamuzi wa mmiliki wa org, sio urahisi, na inapaswa kuwa safu ndogo zaidi inayofunika mwenyeji.

Rekodi amri inayoshindikana, jina la utani, mwenyeji wa utekelezaji na muhuri wa muda, na uache token nje ya kila kitu unachobandika kwenye tiketi. Muhtasari huo wa mistari minne ndio mmiliki wa org anahitaji kuangalia upande wake.

Kagua mtiririko kutoka kwa mwenyeji atakayeutumia

Jaribu kutoka kwa mashine itakayoendesha mzigo wa kazi. Kuingia kulikothibitishwa kwenye kompyuta yako mpito hakuambii chochote kuhusu wakala wa ujenzi katika eneo lingine la mtandao, na tofauti ndiyo hasa unachojaribu kupata.

Tumia usomaji uliidhinishwa usio na madhara kwa ukaguzi, na ikiwa unashindikana hifadhi hitilafu ya kwanza.

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

Wakati kuingia kunafanikiwa lakini swali linashindikana, wagombea waliobaki ni DNS, uelekezaji, uingiliaji wa TLS na sera ya mteja kutoka upande wa org, na kila mmoja ana mmiliki wake. Wakati kuingia yenyewe kunashindikana, kivinjari na CLI kwa hakika haziko kwenye mwenyeji mmoja, na marekebisho ni ya mpangilio kati yao sio ya handaki. Uendeshaji otomatiki unapata kanuni moja zaidi: kazi isiyosimamiwa inahitaji kuingia kulikoidhinishwa kwa msingi wa cheti, kwa sababu kikao cha mwingiliano kilichohifadhiwa na kunakiliwa kwa mfanyakazi sio muundo wa utambulisho.