Salesforce CLI saioa VPN baten bidez: CLI, nabigatzailea eta API ostalaria

Salesforce CLI saio-hasierako hutsek arazo bakarra balira bezala jakinarazten dira, eta normalean hiru dira. CLI prozesua nonbait exekutatzen da, web fluxua osatzen duen nabigatzailea nonbait exekutatzen da, eta geroagoko API deia nonbait exekutatzen da, eta hiru leku horiek ez dute zertan ibilbide, ebazle edo baimen-zerrenda bera partekatu. Haiek alderatzea da tunelak benetan zein blokeatzen duen jakiteko modurik azkarrena. Saio-hasieraren irteeran ez da ezer esaten hiruretatik zein huts egin duen.

Hiru ostalari, saio-hasierako historia bat

Web saio-hasierako fluxuak identitate-urratsa nabigatzaile bati ematen dio, eta nabigatzaile hori askotan zure ordenagailu eramangarrian egoten da, CLI urruneko garapen-ostalari batean edo edukiontzi batean dagoen bitartean. Eramangarriak VPN bezeroa du, urruneko ostalariak plataforma-taldeak eman diona du, eta bi antolaketa horietako batek ere ez du bestea automatikoki estaltzen. Egoera-barran dagoen VPN ikonoak ez du ezer esaten bezeroa inoiz exekutatu ez duen ostalari bati buruz.

Saioa hasi ondoren, CLIak bere API eskaerak egiten ditu prozesua bizi den lekutik. Eskaera horiek DNS, bideratze, TLS konfiantza eta org aldeko bezero-autorizazioa behar dituzte, eta horiek lau egiaztapen bereizi dira, bakoitza bere kabuz huts egin dezakeena. Ederki saioa hasi duen nabigatzaile batek ez dizu horietako ezein buruz ezer esaten.

Mantendu bi erdiak denbora-lerro bakarrean, baina puntuatu bereizita. Orduan tiket bakarrean esan daiteke zein erdi hautsi den, jabetzari buruzko eztabaida bihurtu gabe.

Hartu org-aren erregistroa org-arengandik, ez memoriatik

Web fluxuak instantzia URL bat hartzen du eta emaitza alias baten azpian gordetzen du, eta bi balioek org jabearengandik etorri beharko lukete, lankide baten terminal-historialetik beharrean. Tiket zahar batetik kopiatutako sandbox ostalari bat ohiko arrazoia da org okerraren aurka autentifikatzen eta gero kontsulta guztietan huts egiten duen saio-hasiera batentzat.

Erabili instalatutako pluginak dokumentatzen duen forma, zure host eta alias onartuekin. Dokumentazio hori sfdx eta uneko CLIaren artean aldatu ziren banderen erreferentzia da.

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

Goiko ostalari-izena eta aliasa adibideak dira, ez dituzun kopia beharreko balio lehenetsiak. Bete nabigatzaileko identitate- eta MFA-urrats arruntak, haien inguruan scriptak egitearen ordez, eta inoiz ez jarri pasahitzik, saio-identifikatzailerik edo autentikatzaile-hazirik shell komando batean, gonbidapena saltzeko.

Zer frogatzen du cachean gordetako autorizazioak

Tokiko autorizazio-zerrendan agertzen den alias batek frogatzen du saio-hasiera batek behin arrakasta izan zuela makina horretan. Zerrenda tokiko biltegiratzetik irakurtzen da eta ez dio org-ari galdetzen tokenak oraindik funtzionatzen duen baieztatzeko, beraz, itxura osasuntsuko sarrera batek eta baztertutako API dei batek aldi berean egia izan daitezke. Hartu cachea iraganaren erregistrotzat, ez konektibitate-proba bizitzat. Cache egiaztapen batek laguntza-galderari erantzuten dio, baina inoiz ez du konektibitate-ikerketa bat ixten.

Bereizketa bera aplikatzen zaio nabigatzailearen saioari. Oraindik org-a erakusten duen fitxa batek ez du esan nahi CLIaren gordetako tokenak uneko politikarekin bat egiten duenik, tokenaren iraupena, IP murrizketak eta bezero-aplikazioaren arauak API mugan aplikatzen baitira.

Irakurri tokiko erregistroa ezabatu aurretik, aliasa eta org ostalaria laguntzak eskatuko dituen bi datuak baitira. Alias bat kentzea itzulgarria da, baina okerra istripu baten erdian kentzeak bigarren arazo bat besterik ez du gehitzen.

Non baztertzen den API eskaera benetan

Jarraitu eskaera bat hasieratik amaierara eta ohartu zein osagai erantzuten duen. TLS hutsegite batek 403 batetik desberdina den arazoa izendatzen du, eta horrek denbora-muga batetik desberdina den arazoa izendatzen du, eta hiruretatik denbora-muga da tunela lehen susmagarri gisa seinalatzen duen bakarra. Mezua baino lehen errore-klasea irakurtzeak asmatze asko aurreztatzen ditu. Idatzi klasea berriro ezer exekutatu aurretik.

Iturburu-helbide murrizketak saio-hasiera bat funtzionatzen duen eta kontsulta batek ez duen kasua dira, nabigatzailearen fluxuak eta API deiak helbide ezberdinetatik atera baitaitezke. Hori baimen-zerrenda zabalago batekin konpontzea org jabearen erabakia da, ez erosotasuna, eta ostalaria estaltzen duen barrutirik txikiena izan behar luke.

Erregistratu huts egiten duen komandoa, aliasa, exekuzio-ostalaria eta denbora-zigilua, eta utzi tokena tiketaren itsasten duzun guztitik kanpo. Lau lerroko laburpen hori da org jabeak bere aldea egiaztatzeko behar duena.

Egiaztatu fluxua erabiliko duen ostalaritik

Probatu karga-lana exekutatuko duen makinatik. Zure eramangarrian egiaztatutako saio-hasiera batek ez du ezer esaten beste sare-eremu bateko build agente bati buruz, eta aldea aurkitzen saiatzen ari zaren gauza bera da.

Erabili baimendutako irakurketa kaltegabe bat egiaztapenerako, eta huts egiten badu, gorde lehen errorea.

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

Saio-hasierak arrakasta duenean baina kontsultak huts egiten duenean, gainerako hautagaiak DNS, bideratzea, TLS artezkaritza eta org aldeko bezero-politika dira, eta bakoitzak bere jabea du. Saio-hasierak berak huts egiten duenean, nabigatzailea eta CLIa ziurrenik ez daude ostalari berean, eta konponketa haien arteko antolaketari dagokio, ez tunelari. Automatizazioak arau bat gehiago jasotzen du: gainbegiratu gabeko lan batek ziurtagirian oinarritutako saio-hasiera onartu bat behar du, langile bati kopiatutako cachean gordetako saio interaktiboa ez baita identitate-diseinu bat.