Hyrja në Salesforce CLI përmes një VPN: CLI, shfletuesi dhe hosti API

Dështimet e hyrjes në Salesforce CLI raportohen si një problem i vetëm dhe zakonisht janë tre. Procesi CLI ekzekutohet diku, shfletuesi që përfundon rrjedhën e uebit ekzekutohet diku, dhe thirrja e mëvonshme API ekzekutohet diku, dhe këto tre vende nuk duhet të ndajnë një rrugë, një zgjidhës ose një listë të lejuar. Krahasimi i tyre është mënyra më e shpejtë për të zbuluar se cilin po bllokon në të vërtetë tuneli. Asgjë në daljen e hyrjes nuk thotë se cili nga të tre dështoi.

Tre hoste, një histori hyrjeje

Rrjedha e hyrjes në ueb ia dorëzon hapin e identitetit një shfletuesi, dhe ai shfletues është shpesh në laptopin tuaj ndërsa CLI-ja qëndron në një host të largët zhvillimi ose në një kontejner. Laptopi ka klientin VPN, hosti i largët ka atë që i dha ekipi i platformës, dhe asnjëra nga të dyja rregullimet nuk e mbulon automatikisht tjetrën. Një ikonë VPN në shiritin e statusit nuk thotë asgjë për një host që nuk e ekzekutoi kurrë klientin.

Pas hyrjes, CLI-ja i bën vetë kërkesat e saj API nga aty ku jeton procesi. Këto kërkesa kanë nevojë për DNS, rrugëtim, besim TLS dhe autorizim klienti nga ana e org-ut, të cilat janë katër kontrolle të ndara dhe secili mund të dështojë vetë. Një shfletues që u identifikua bukur nuk ju thotë asgjë për asnjë prej tyre.

Mbajini të dyja gjysmat në një vijë të vetme kohore, por vlerësojini veçmas. Atëherë një biletë e vetme mund të thotë cila gjysmë u prish pa e kthyer në një debat për pronësinë.

Merrni të dhënën e org-ut nga org-u, jo nga kujtesa

Rrjedha e uebit merr një URL instance dhe e ruan rezultatin nën një pseudonim, dhe të dyja vlerat duhet të vijnë nga pronari i org-ut dhe jo nga historia e terminalit të një kolegu. Një host sandbox i kopjuar nga një biletë e vjetër është një shkak i zakonshëm i një hyrjeje që vërtetohet kundër org-ut të gabuar dhe më pas dështon në çdo kërkesë.

Përdorni formën që dokumenton shtesa e instaluar, me hostin dhe pseudonimin tuaj të miratuar. Ai dokumentacion është referenca për flamujt që ndryshuan midis sfdx dhe CLI-së aktuale.

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

Emri i hostit dhe pseudonimi më sipër janë shembuj, jo vlera të paracaktuara që duhet të kopjoni. Përfundoni hapat e zakonshëm të identitetit të shfletuesit dhe MFA, në vend që t'i anashkaloni me një skript, dhe kurrë mos vendosni një fjalëkalim, një identifikues sesioni ose një farë vërtetuesi në një komandë shell për të kaluar kërkesën.

Çfarë provon autorizimi i ruajtur në cache

Një pseudonim që shfaqet në listën lokale të autorizimeve provon se një hyrje dikur pati sukses në atë makinë. Lista lexohet nga ruajtja lokale dhe nuk kontakton org-un për të konfirmuar se tokeni ende funksionon, kështu që një zë i shëndetshëm në dukje dhe një thirrje API e refuzuar mund të jenë të dyja të vërteta. Trajtojeni cache-in si një regjistrim të së shkuarës, jo si një test i lidhshmërisë së drejtpërdrejtë. Një kontroll cache-i i përgjigjet një pyetjeje suporti, por nuk e mbyll kurrë një hetim lidhshmërie.

I njëjti dallim vlen për sesionin e shfletuesit. Një skedë që ende shfaq org-un nuk do të thotë se tokeni i ruajtur i CLI-së përputhet me politikën aktuale, sepse jetëgjatësia e tokenit, kufizimet e IP dhe rregullat e aplikacionit klient zbatohen në kufirin e API-së.

Lexoni regjistrimin lokal përpara se ta fshini, sepse pseudonimi dhe hosti i org-ut janë dy faktet që do të kërkojë suporti. Heqja e një pseudonimi është e kthyeshme, por heqja e atij të gabuar në mes të një incidenti thjesht shton një problem të dytë.

Ku refuzohet në të vërtetë kërkesa API

Ndiqni një kërkesë nga fillimi në fund dhe vini re cila komponent përgjigjet. Një dështim TLS emërton një problem tjetër nga një 403, i cili emërton një problem tjetër nga një skadim kohe, dhe skadimi i kohës është i vetmi nga të tre që tregon tunelin si të dyshuarin e parë. Leximi i klasës së gabimit përpara mesazhit kursen shumë hamendje. Shkruani klasën përpara se të ekzekutoni përsëri çdo gjë.

Kufizimet e adresës burimore janë rasti që prodhon një hyrje që funksionon dhe një kërkesë që nuk funksionon, sepse rrjedha e shfletuesit dhe thirrja API mund të dalin përmes adresave të ndryshme. Rregullimi i kësaj me një listë më të gjerë të lejuar është vendim i pronarit të org-ut, jo lehtësi, dhe duhet të jetë diapazoni më i vogël që mbulon hostin.

Regjistroni komandën që dështon, pseudonimin, hostin e ekzekutimit dhe vulën kohore, dhe lëreni tokenin jashtë çdo gjëje që ngjitni në biletë. Ai përmbledhje prej katër rreshtash është ajo që i nevojitet pronarit të org-ut për të kontrolluar anën e tij.

Kontrolloni rrjedhën nga hosti që do ta përdorë

Testoni nga makina që do të ekzekutojë ngarkesën e punës. Një hyrje e verifikuar në laptopin tuaj nuk thotë asgjë për një agjent ndërtimi në një zonë tjetër rrjeti, dhe dallimi është pikërisht ajo që po përpiqeni të gjeni.

Përdorni një lexim të autorizuar të padëmshëm për kontrollin, dhe nëse dështon, mbani gabimin e parë.

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

Kur hyrja ka sukses por kërkesa dështon, kandidatët e mbetur janë DNS, rrugëtimi, përgjimi TLS dhe politika e klientit nga ana e org-ut, dhe secili ka pronarin e vet. Kur dështon vetë hyrja, shfletuesi dhe CLI-ja me gjasë nuk janë në të njëjtin host, dhe rregullimi i takon rregullimit midis tyre dhe jo tunelit. Automatizimi merr një rregull më shumë: një punë pa mbikëqyrje ka nevojë për një hyrje të miratuar të bazuar në certifikatë, sepse një sesion interaktiv i ruajtur në cache i kopjuar te një punëtor nuk është një dizajn identiteti.