Salesforce CLI-bejelentkezés VPN-en át: CLI, böngésző és API-gazdagép

A Salesforce CLI bejelentkezési hibáit egyetlen problémaként jelentik, pedig általában hárman vannak. A CLI-folyamat valahol fut, a webes folyamatot befejező böngésző valahol fut, és a későbbi API-hívás valahol fut, és ennek a három helynek nem kell osztoznia útvonalon, feloldón vagy engedélyezési listán. Összehasonlításuk a leggyorsabb módja annak kiderítésére, melyiket blokkolja valójában az alagút. A bejelentkezés kimenete semmit sem mond arról, melyik a három közül hibázott.

Három gazdagép, egy bejelentkezési történet

A webes bejelentkezési folyamat a böngészőnek adja át az identitás lépését, és az a böngésző gyakran a laptopon van, miközben a CLI egy távoli fejlesztői gazdagépen vagy konténerben ül. A laptopon VPN-kliens van, a távoli gazdagépen az van, amit a platformcsapat adott neki, és a két elrendezés közül egyik sem fedi le automatikusan a másikat. Az állapotsor VPN-ikonja semmit sem mond egy olyan gazdagépről, amely soha nem futtatta a klienst.

Bejelentkezés után a CLI a saját API-kéréseit onnan indítja, ahol a folyamat él. Ezeknek a kéréseknek DNS-re, útválasztásra, TLS-bizalomra és az org oldalán ügyfélengedélyezésre van szükségük, ami négy külön ellenőrzés, és mindegyik önállóan is elbukhat. Egy szépen bejelentkezett böngésző semmit sem mond ezek közül egyikről sem.

Tartsa mindkét felét egy idővonalon, de külön pontozza őket. Így egyetlen jegy is meg tudja mondani, melyik fél tört el, anélkül hogy tulajdonjogi vitává válna.

Az org-bejegyzést az orgtól vegye, ne az emlékezetből

A webes folyamat vesz egy példány-URL-t, és az eredményt alias alatt tárolja, és mindkét értéknek az org tulajdonosától kell származnia, nem egy kolléga terminál-előzményeiből. Egy régi jegyből másolt sandbox-gazdagép gyakori oka annak a bejelentkezésnek, amely a rossz orghoz hitelesít, majd minden lekérdezésnél elbukik.

Használja azt a formát, amelyet a telepített bővítmény dokumentál, a saját jóváhagyott gazdagépével és aliasával. Az a dokumentáció a referencia azokhoz a kapcsolókhoz, amelyek az sfdx és a jelenlegi CLI között megváltoztak.

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

A fenti gazdagépnév és alias példák, nem másolandó alapértékek. Végezze el a szokásos böngészős identitás- és MFA-lépéseket, ahelyett hogy szkripttel megkerülné őket, és soha ne tegyen jelszót, munkamenet-azonosítót vagy hitelesítő magot egy shell-parancsba a felszólítás megkerüléséhez.

Mit bizonyít a gyorsítótárazott engedélyezés

A helyi engedélyezési listán megjelenő alias azt bizonyítja, hogy a bejelentkezés egyszer már sikerült azon a gépen. A listát a helyi tárolóból olvassa be, és nem lép kapcsolatba az orggal annak megerősítéséhez, hogy a token még működik, így egy egészségesnek látszó bejegyzés és egy elutasított API-hívás egyszerre is igaz lehet. Tekintse a gyorsítótárat a múlt nyilvántartásának, nem élő kapcsolatvizsgálatnak. A gyorsítótár-ellenőrzés válaszol egy támogatási kérdésre, de soha nem zár le egy kapcsolatvizsgálatot.

Ugyanez a megkülönböztetés érvényes a böngésző munkamenetére. Egy lap, amely még mutatja az orgot, nem jelenti azt, hogy a CLI tárolt tokenje megfelel a jelenlegi szabályzatnak, mert a token élettartama, az IP-korlátozások és az ügyfélalkalmazás szabályai az API határán érvényesülnek.

Olvassa el a helyi bejegyzést, mielőtt törölné, mert az alias és az org-gazdagép az a két tény, amelyet a támogatás kérni fog. Egy alias eltávolítása visszafordítható, de a rossz eltávolítása egy incidens közepén csak egy második problémát ad hozzá.

Hol utasítja el valójában az API-kérés

Kövessen végig egy kérést, és jegyezze meg, melyik komponens válaszol. Egy TLS-hiba más problémát nevez meg, mint egy 403, amely más problémát nevez meg, mint egy időtúllépés, és az időtúllépés az egyetlen a három közül, amely az alagútra mutat első gyanúsítottként. A hibaosztály elolvasása az üzenet előtt sok találgatást megspórol. Jegyezze fel az osztályt, mielőtt bármit újrafuttat.

A forrás-cím korlátozásai az az eset, amely működő bejelentkezést és nem működő lekérdezést eredményez, mert a böngészőfolyamat és az API-hívás különböző címeken léphet ki. Ennek szélesebb engedélyezési listával való javítása az org tulajdonosának döntése, nem kényelmi kérdés, és a legkisebb tartománynak kell lennie, amely lefedi a gazdagépet.

Rögzítse a sikertelen parancsot, az aliast, a végrehajtási gazdagépet és az időbélyeget, és hagyja a tokent azon kívül, amit a jegybe beilleszt. Ez a négy soros összefoglaló az, amire az org tulajdonosának szüksége van a saját oldala ellenőrzéséhez.

Ellenőrizze a folyamatot arról a gazdagépről, amely használni fogja

Teszteljen arról a gépről, amely a munkaterhelést futtatni fogja. A laptopján ellenőrzött bejelentkezés semmit sem mond egy másik hálózati zónában lévő build-ügynökről, és a különbség pontosan az, amit keresni próbál.

Az ellenőrzéshez használjon ártalmatlan engedélyezett olvasást, és ha elbukik, tartsa meg az első hibát.

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

Amikor a bejelentkezés sikerül, de a lekérdezés elbukik, a fennmaradó jelöltek a DNS, az útválasztás, a TLS-elfogás és az org oldalán érvényes ügyfélszabályzat, és mindegyiknek megvan a maga tulajdonosa. Amikor maga a bejelentkezés bukik el, a böngésző és a CLI valószínűleg nincs ugyanazon a gazdagépen, és a javítás a köztük lévő elrendezéshez tartozik, nem az alagúthoz. Az automatizálás még egy szabályt kap: egy felügyelet nélküli feladatnak jóváhagyott tanúsítványalapú bejelentkezésre van szüksége, mert a munkásra másolt gyorsítótárazott interaktív munkamenet nem identitástervezés.