Salesforce CLI -kirjautuminen VPN:n yli: CLI, selain ja API-isäntä

Salesforce CLI -kirjautumisen virheet raportoidaan yhtenä ongelmana ja niitä on yleensä kolme. CLI-prosessi toimii jossain, verkkovirran suorittava selain toimii jossain ja myöhempi API-kutsu toimii jossain, eikä näiden kolmen paikan tarvitse jakaa reittiä, resolveria tai sallittujen luetteloa. Niiden vertailu on nopein tapa selvittää, minkä tunneli todella estää. Mikään kirjautumisen tulosteessa ei kerro, mikä kolmesta epäonnistui.

Kolme isäntää, yksi kirjautumistarina

Verkkokirjautumisen virta antaa identiteettivaiheen selaimelle, ja se selain on usein kannettavallasi, kun CLI istuu etäisellä kehitysisännällä tai kontissa. Kannettavalla on VPN-asiakas, etäisellä isännällä on se, mitä alusta-tiimi antoi sille, eikä kumpikaan järjestely kata toista automaattisesti. Tilapalkin VPN-kuvake ei kerro mitään isännästä, joka ei koskaan käynnistänyt asiakasta.

Kirjautumisen jälkeen CLI tekee omat API-pyyntönsä sieltä, missä prosessi elää. Nämä pyynnöt tarvitsevat DNS:n, reitityksen, TLS-luottamuksen ja asiakkaan valtuutuksen orgin puolella, eli neljä erillistä tarkistusta, ja jokainen voi epäonnistua yksinään. Selain, joka kirjautui kauniisti sisään, ei kerro sinulle niistä yhdestäkään mitään.

Pidä molemmat puoliskot yhdellä aikajanalla, mutta arvioi ne erikseen. Silloin yksi tiketti voi kertoa, kumpi puolisko hajosi, ilman että siitä tulee omistajuuskiista.

Ota orgin merkintä orgilta, älä muistista

Verkkovirta ottaa instanssin URL:n ja tallentaa tuloksen aliaksen alle, ja molempien arvojen tulisi tulla orgin omistajalta eikä kollegan päätelaitteen historiasta. Vanhasta tiketistä kopioitu sandbox-isäntä on yleinen syy kirjautumiselle, joka todentaa väärään orgiin ja epäonnistuu sitten jokaisessa kyselyssä.

Käytä muotoa, jonka asennettu liitännäinen dokumentoi, omalla hyväksytyllä isännälläsi ja aliaksellasi. Se dokumentaatio on viite lipuille, jotka muuttuivat sfdx:n ja nykyisen CLIn välillä.

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

Yllä oleva isäntänimi ja alias ovat esimerkkejä, eivät oletusarvoja, jotka sinun pitäisi kopioida. Suorita tavalliset selaimen identiteetti- ja MFA-vaiheet sen sijaan, että kiertäisit ne skriptillä, äläkä koskaan laita salasanaa, istunnon tunnistetta tai todennuslaitteen siementä komentorivikomentoon kehotteen ohittamiseksi.

Mitä välimuistiin tallennettu valtuutus todistaa

Paikallisessa valtuutusluettelossa näkyvä alias todistaa, että kirjautuminen onnistui kerran kyseisellä koneella. Luettelo luetaan paikallisesta tallennuksesta eikä ota yhteyttä orgiin vahvistaakseen, että token toimii edelleen, joten terveeltä näyttävä merkintä ja hylätty API-kutsu voivat molemmat olla totta. Kohtele välimuistia menneisyyden kirjauksena, älä elävänä yhteyden testinä. Välimuistin tarkistus vastaa tukikysymykseen, mutta ei koskaan sulje yhteyden tutkintaa.

Sama ero koskee selaimen istuntoa. Välilehti, joka näyttää yhä orgin, ei tarkoita, että CLIn tallentama token vastaa nykyistä käytäntöä, koska tokenin käyttöikä, IP-rajoitukset ja asiakassovelluksen säännöt valvotaan API:n rajalla.

Lue paikallinen merkintä ennen sen poistamista, sillä alias ja orgin isäntä ovat ne kaksi tosiasiaa, joita tuki kysyy. Aliaksen poistaminen on peruutettavissa, mutta väärän poistaminen kesken tapauksen lisää vain toisen ongelman.

Missä API-pyyntö todella hylätään

Seuraa yhtä pyyntöä alusta loppuun ja pane merkille, mikä komponentti vastaa. TLS-virhe nimeää eri ongelman kuin 403, joka nimeää eri ongelman kuin aikakatkaisu, ja aikakatkaisu on ainoa kolmesta, joka osoittaa tunneliin ensimmäisenä epäiltynä. Virheluokan lukeminen ennen viestiä säästää paljon arvailua. Kirjoita luokka muistiin ennen kuin ajat mitään uudelleen.

Lähdeosoitteen rajoitukset ovat tapaus, joka tuottaa toimivan kirjautumisen ja toimimattoman kyselyn, koska selainvirta ja API-kutsu voivat lähteä eri osoitteista. Sen korjaaminen laajemmalla sallittujen luettelolla on orgin omistajan päätös, ei mukavuus, ja sen pitäisi olla pienin isännän kattava alue.

Tallenna epäonnistuva komento, alias, suoritusisäntä ja aikaleima, ja jätä token pois kaikesta, mitä liität tikettiin. Tämä nelirivinen yhteenveto on se, mitä orgin omistaja tarvitsee tarkistaakseen oman puolensa.

Tarkista virta isännältä, joka sitä tulee käyttämään

Testaa koneelta, joka tulee suorittamaan työkuorman. Kannettavallasi vahvistettu kirjautuminen ei kerro mitään toisessa verkkovyöhykkeessä olevasta build-agentista, ja ero on juuri se, mitä yrität löytää.

Käytä tarkistukseen vaaratonta valtuutettua lukua, ja jos se epäonnistuu, säilytä ensimmäinen virhe.

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

Kun kirjautuminen onnistuu mutta kysely epäonnistuu, jäljellä olevat ehdokkaat ovat DNS, reititys, TLS-välitys ja asiakaskäytäntö orgin puolella, ja jokaisella on oma omistajansa. Kun kirjautuminen itse epäonnistuu, selain ja CLI eivät todennäköisesti ole samalla isännällä, ja korjaus kuuluu niiden väliseen järjestelyyn eikä tunneliin. Automaatio saa vielä yhden säännön: valvomaton työ tarvitsee hyväksytyn varmenneperusteisen kirjautumisen, koska työntekijälle kopioitu välimuistiin tallennettu interaktiivinen istunto ei ole identiteettisuunnittelu.