Salesforce CLI մուտքագրում VPN-ի միջով․ 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 քայլերը՝ դրանք սկրիպտով շրջանցելու փոխարեն, և երբեք չդնեք գաղտնաբառ, սեսիայի նույնացուցիչ կամ նույնականացուցիչի սերմ shell հրամանի մեջ՝ հուշումը բաց թողնելու համար։

Ինչ է ապացուցում քեշված լիազորումը

Տեղական լիազորման ցանկում հայտնված անունը ապացուցում է, որ մուտքագրումը մի անգամ հաջողվել է այդ մեքենայում։ Ցանկը կարդացվում է տեղական պահոցից և չի կապվում org-ի հետ՝ հաստատելու, որ թոքենը դեռ աշխատում է, ուստի առողջ տեսք ունեցող գրառումը և մերժված API կանչը կարող են միաժամանակ ճիշտ լինել։ Քեշին վերաբերվեք որպես անցյալի գրառում, ոչ որպես կենդանի կապի թեստ։ Քեշի ստուգումը պատասխանում է աջակցության հարցին, բայց երբեք չի փակում կապի հետաքննությունը։

Նույն տարբերությունը վերաբերում է զննարկիչի սեսիային։ Ներդիրը, որը դեռ ցույց է տալիս org-ը, չի նշանակում, որ CLI-ի պահված թոքենը համապատասխանում է ընթացիկ քաղաքականությանը, քանի որ թոքենի կյանքը, IP սահմանափակումները և հաճախորդ հավելվածի կանոնները կիրառվում են API սահմանին։

Կարդացեք տեղական գրառումը նախքան այն ջնջելը, քանի որ անունը և org հոսթը այն երկու փաստերն են, որ աջակցությունը կհարցնի։ Անունը հեռացնելը շրջելի է, բայց սխալը միջադեպի կեսին հեռացնելը պարզապես ավելացնում է երկրորդ խնդիր։

Որտեղ է API հարցումն իրականում մերժվում

Հետևեք մեկ հարցման սկզբից մինչև վերջ և նշեք, թե որ բաղադրիչն է պատասխանում։ TLS ձախողումը այլ խնդիր է անվանում, քան 403-ը, որը այլ խնդիր է անվանում, քան ժամանակի սպառումը, և ժամանակի սպառումը երեքից միակն է, որը թունելին մատնանշում է որպես առաջին կասկածյալ։ Սխալի դասը հաղորդագրությունից առաջ կարդալը խնայում է շատ գուշակություն։ Գրեք դասը նախքան որևէ բան նորից գործարկելը։

Աղբյուրի հասցեի սահմանափակումները այն դեպքն են, որը տալիս է աշխատող մուտքագրում և չաշխատող հարցում, քանի որ զննարկիչի հոսքը և API կանչը կարող են դուրս գալ տարբեր հասցեներով։ Դա ավելի լայն թույլատրվածների ցանկով ուղղելը org-ի սեփականատիրոջ որոշումն է, ոչ հարմարավետություն, և այն պետք է լինի ամենափոքր տիրույթը, որը ծածկում է հոսթը։

Արձանագրեք ձախողված հրամանը, անունը, կատարման հոսթը և ժամանակի նշանը, և թոքենը թողեք այն ամենից դուրս, ինչ կպցնում եք տոմսի մեջ։ Այդ չորս տողանոց ամփոփումն է, ինչ org-ի սեփականատերը պետք է իր կողմը ստուգելու համար։

Ստուգեք հոսքը այն հոսթից, որը կօգտագործի այն

Փորձարկեք այն մեքենայից, որը կկատարի աշխատանքային բեռը։ Ձեր նոթբուքում հաստատված մուտքագրումը ոչինչ չի ասում մեկ այլ ցանցային գոտու կառուցման գործակալի մասին, և տարբերությունը հենց այն է, ինչ փորձում եք գտնել։

Ստուգման համար օգտագործեք անվնաս լիազորված ընթերցում, և եթե ձախողվի, պահեք առաջին սխալը։

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-ն հավանաբար նույն հոսթում չեն, և ուղղումը պատկանում է նրանց միջև դասավորությանը, ոչ թե թունելին։ Ավտոմատացումը ստանում է ևս մեկ կանոն՝ չհսկվող աշխատանքին անհրաժեշտ է հաստատված վկայագրի վրա հիմնված մուտքագրում, քանի որ աշխատողին պատճենված քեշված ինտերակտիվ սեսիան ինքնության ձևավորում չէ։