Salesforce CLI-aanmelding oor 'n VPN: CLI, blaaier en API-gasheer

Salesforce CLI-aanmeldingsfoute word as een probleem gerapporteer en is gewoonlik drie. Die CLI-proses loop êrens, die blaaier wat die webvloei voltooi, loop êrens, en die latere API-oproep loop êrens, en daardie drie plekke hoef nie 'n roete, 'n resolusiepunt of 'n toelatingslys te deel nie. Om hulle te vergelyk is die vinnigste manier om uit te vind watter een die tonnel werklik blokkeer. Niks in die aanmeldingsuitset noem watter van die drie misluk het nie.

Drie gashere, een aanmeldingsverhaal

Die web-aanmeldingsvloei gee die identiteitstap aan 'n blaaier oor, en daardie blaaier is dikwels op jou skootrekenaar terwyl die CLI op 'n afgeleë ontwikkelingsgasheer of in 'n houer sit. Die skootrekenaar het die VPN-kliënt, die afgeleë gasheer het wat die platformspan ook al gegee het, en nie een van die twee reëlings dek outomaties die ander nie. 'n VPN-ikoon in die statusbalk sê niks oor 'n gasheer wat nooit die kliënt laat loop het nie.

Ná aanmelding maak die CLI sy eie API-versoeke van waar die proses ook al leef. Daardie versoeke benodig DNS, roetering, TLS-vertroue en kliëntmagtiging aan die organisasiekant, wat vier afsonderlike kontroles is wat elkeen op sy eie kan misluk. 'n Blaaier wat pragtig aangemeld het, sê niks oor enige van hulle nie.

Hou albei helftes in een tydlyn, maar beoordeel hulle afsonderlik. 'n Enkele kaartjie kan dan sê watter helfte gebreek het sonder om dit in 'n argument oor eienaarskap te verander.

Neem die organisasie-inskrywing by die organisasie, nie uit die geheue nie

Die webvloei neem 'n instansie-URL en stoor die resultaat onder 'n alias, en albei waardes moet by die organisasie-eienaar kom eerder as uit 'n kollega se terminaalgeskiedenis. 'n Sandbox-gasheer wat uit 'n ou kaartjie gekopieer is, is 'n algemene oorsaak van 'n aanmelding wat teen die verkeerde organisasie authentiseer en dan elke navraag laat misluk.

Gebruik die vorm wat die geïnstalleerde inprop dokumenteer, met jou eie goedgekeurde gasheer en alias. Daardie dokumentasie is die verwysing vir vlae wat tussen sfdx en die huidige CLI verander het.

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

Die gasheernaam en alias hierbo is voorbeelde, nie verstekwaardes wat jy moet kopieer nie. Voltooi die normale blaaier-identiteit- en MFA-stappe eerder as om daaromheen te skrip, en plaas nooit 'n wagwoord, sessie-identifiseerder of verifieerder-saad in 'n skelopdrag om die opdrag te omseil nie.

Wat die gekasde magtiging bewys

’n Alias wat in die plaaslike magtigingslys verskyn, bewys dat 'n aanmelding een keer op daardie masjien geslaag het. Die lys word uit plaaslike berging gelees en kontak nie die organisasie om te bevestig dat die token nog werk nie, so 'n gesonde voorkoms en 'n verwerpte API-oproep kan albei waar wees. Behandel die kas as 'n rekord van die verlede, nie as 'n lewendige verbindingstoets nie. ’n Kas-kontrole beantwoord 'n ondersteuningsvraag, maar dit sluit nooit 'n verbindingsondersoek nie.

Dieselfde onderskeid geld vir die blaaier-sessie. ’n Oortjie wat nog die organisasie wys, beteken nie dat die CLI se gestoorde token by die huidige beleid pas nie, want token-leeftyd, IP-beperkings en kliëntprogram-reëls word by die API-grens afgedwing.

Lees die plaaslike rekord voordat jy dit uitvee, want die alias en die organisasie-gasheer is die twee feite wat ondersteuning sal vra. Om 'n alias te verwyder is omkeerbaar, maar om die verkeerde een midde-in 'n voorval te verwyder, voeg net 'n tweede probleem by.

Waar die API-versoek werklik verwerp word

Volg een versoek van begin tot einde en let op watter komponent antwoord. ’n TLS-fout noem 'n ander probleem as 'n 403, wat 'n ander probleem noem as 'n tydverstryking, en 'n tydverstryking is die enigste van die drie wat die tonnel as eerste verdagte aanwys. Om die foutklas voor die boodskap te lees, spaar baie raaiwerk. Skryf die klas neer voordat jy enigiets weer laat loop.

Bronadres-beperkings is die geval wat 'n aanmelding lewer wat werk en 'n navraag wat nie werk nie, want die blaaier-vloei en die API-oproep kan deur verskillende adresse uitgaan. Om dit met 'n wyer toelatingslys reg te maak, is 'n besluit van die organisasie-eienaar, nie 'n gerief nie, en dit moet die kleinste reeks wees wat die gasheer dek.

Teken die mislukte opdrag, die alias, die uitvoeringsgasheer en die tydstempel vas, en laat die token uit alles wat jy in die kaartjie plak. Daardie vier-reël-samevatting is wat die organisasie-eienaar nodig het om hulle kant na te gaan.

Kontroleer die vloei vanaf die gasheer wat dit gaan gebruik

Toets vanaf die masjien wat die werklaag gaan loop. ’n Aanmelding wat op jou skootrekenaar geverifieer is, sê niks oor 'n bou-agent in 'n ander netwerksone nie, en die verskil is presies wat jy probeer vind.

Gebruik 'n onskadelike gemagtigde lees vir die kontrole, en hou die eerste fout as dit misluk.

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

Wanneer die aanmelding slaag maar die navraag misluk, is die oorblywende kandidate DNS, roetering, TLS-onderskepping en kliëntbeleid aan die organisasiekant, en elkeen het sy eie eienaar. Wanneer die aanmelding self misluk, is die blaaier en die CLI waarskynlik nie op dieselfde gasheer nie, en die regstelling hoort by die reëling tussen hulle eerder as by die tonnel. Outomatisering kry nog een reël: ’n onbewaakte taak benodig 'n goedgekeurde sertifikaatgebaseerde aanmelding, want 'n gekasde interaktiewe sessie wat na 'n werker gekopieer is, is nie 'n identiteitsontwerp nie.