Accesso a Salesforce CLI tramite VPN: CLI, browser e host API

Gli errori di accesso a Salesforce CLI vengono segnalati come un unico problema e di solito sono tre. Il processo CLI viene eseguito da qualche parte, il browser che completa il flusso web viene eseguito da qualche parte e la chiamata API successiva viene eseguita da qualche parte, e questi tre luoghi non devono condividere una rotta, un resolver o una lista di autorizzati. Confrontarli è il modo più rapido per scoprire quale sta effettivamente bloccando il tunnel. Nulla nell’output dell’accesso indica quale dei tre ha fallito.

Tre host, una storia di accesso

Il flusso di accesso web affida il passaggio dell’identità a un browser, e quel browser è spesso sul portatile mentre la CLI è su un host di sviluppo remoto o in un container. Il portatile ha il client VPN, l’host remoto ha ciò che gli ha dato il team di piattaforma, e nessuna delle due disposizioni copre automaticamente l’altra. Un’icona VPN nella barra di stato non dice nulla su un host che non ha mai eseguito il client.

Dopo l’accesso, la CLI effettua le proprie richieste API da dove vive il processo. Queste richieste necessitano di DNS, routing, fiducia TLS e autorizzazione client lato org, che sono quattro controlli separati e ciascuno può fallire da solo. Un browser che ha eseguito l’accesso benissimo non ti dice nulla su nessuno di essi.

Mantieni entrambe le metà su un’unica sequenza temporale, ma valuta separatamente. Così un singolo ticket può dire quale metà si è rotta senza trasformarlo in una discussione sulla proprietà.

Prendi la voce dell’org dall’org, non dalla memoria

Il flusso web prende un URL di istanza e memorizza il risultato sotto un alias, ed entrambi i valori dovrebbero venire dal proprietario dell’org anziché dalla cronologia del terminale di un collega. Un host sandbox copiato da un vecchio ticket è una causa comune di un accesso che si autentica sull’org sbagliata e poi fallisce a ogni query.

Usa la forma documentata dal plugin installato, con il tuo host e alias approvati. Quella documentazione è il riferimento per i flag che sono cambiati tra sfdx e la CLI attuale.

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

Il nome host e l’alias qui sopra sono esempi, non valori predefiniti che dovresti copiare. Completa i normali passaggi di identità del browser e MFA invece di aggirarli con uno script, e non inserire mai una password, un identificatore di sessione o un seme dell’autenticatore in un comando shell per saltare la richiesta.

Cosa dimostra l’autorizzazione nella cache

Un alias che compare nell’elenco delle autorizzazioni locale dimostra che un accesso è riuscito una volta su quella macchina. L’elenco viene letto dall’archivio locale e non contatta l’org per confermare che il token funzioni ancora, quindi una voce dall’aspetto sano e una chiamata API rifiutata possono essere entrambe vere. Tratta la cache come un registro del passato, non come un test di connettività dal vivo. Un controllo della cache risponde a una domanda di supporto, ma non chiude mai un’indagine sulla connettività.

La stessa distinzione vale per la sessione del browser. Una scheda che mostra ancora l’org non significa che il token memorizzato della CLI corrisponda alla politica attuale, perché la durata del token, le restrizioni IP e le regole dell’app client si applicano al confine dell’API.

Leggi il record locale prima di eliminarlo, dato che l’alias e l’host dell’org sono i due fatti che il supporto chiederà. Rimuovere un alias è reversibile, ma rimuovere quello sbagliato nel mezzo di un incidente aggiunge solo un secondo problema.

Dove viene effettivamente rifiutata la richiesta API

Segui una richiesta dall’inizio alla fine e annota quale componente risponde. Un errore TLS nomina un problema diverso da un 403, che nomina un problema diverso da un timeout, e il timeout è l’unico dei tre che indica il tunnel come primo sospetto. Leggere la classe di errore prima del messaggio risparmia molte congetture. Annota la classe prima di rieseguire qualsiasi cosa.

Le restrizioni sull’indirizzo di origine sono il caso che produce un accesso che funziona e una query che non funziona, perché il flusso del browser e la chiamata API possono uscire da indirizzi diversi. Correggerlo con una lista di autorizzati più ampia è una decisione del proprietario dell’org, non una comodità, e dovrebbe essere l’intervallo più piccolo che copre l’host.

Cattura il comando che fallisce, l’alias, l’host di esecuzione e il timestamp, e lascia il token fuori da tutto ciò che incolli nel ticket. Quel riepilogo di quattro righe è ciò di cui il proprietario dell’org ha bisogno per controllare il proprio lato.

Verifica il flusso dall’host che lo userà

Testa dalla macchina che eseguirà il carico di lavoro. Un accesso verificato sul tuo portatile non dice nulla su un agente di build in un’altra zona di rete, e la differenza è esattamente ciò che stai cercando di trovare.

Usa una lettura autorizzata innocua per il controllo, e conserva il primo errore se fallisce.

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

Quando l’accesso riesce ma la query fallisce, i candidati rimanenti sono DNS, routing, intercettazione TLS e politica client lato org, e ciascuno ha il proprio proprietario. Quando fallisce l’accesso stesso, il browser e la CLI probabilmente non sono sullo stesso host, e la correzione appartiene alla disposizione tra loro anziché al tunnel. L’automazione riceve un’altra regola: un lavoro non presidiato ha bisogno di un accesso approvato basato su certificato, perché una sessione interattiva nella cache copiata su un worker non è un progetto di identità.