Inicio de sesión de Salesforce CLI a través de una VPN: CLI, navegador y host de API

Los fallos de inicio de sesión de Salesforce CLI se reportan como un solo problema y suelen ser tres. El proceso de la CLI se ejecuta en algún sitio, el navegador que completa el flujo web se ejecuta en algún sitio y la llamada posterior a la API se ejecuta en algún sitio, y esos tres lugares no tienen por qué compartir una ruta, un resolutor ni una lista de permitidos. Compararlos es la forma más rápida de averiguar cuál está bloqueando realmente el túnel. Nada en la salida del inicio de sesión indica cuál de los tres falló.

Tres hosts, una historia de inicio de sesión

El flujo de inicio de sesión web entrega el paso de identidad a un navegador, y ese navegador suele estar en su portátil mientras la CLI está en un host de desarrollo remoto o en un contenedor. El portátil tiene el cliente VPN, el host remoto tiene lo que le dio el equipo de plataforma, y ninguna de las dos configuraciones cubre automáticamente a la otra. Un icono de VPN en la barra de estado no dice nada sobre un host que nunca ejecutó el cliente.

Después del inicio de sesión, la CLI hace sus propias solicitudes a la API desde donde viva el proceso. Esas solicitudes necesitan DNS, enrutamiento, confianza TLS y autorización de cliente por parte de la org, que son cuatro comprobaciones separadas y cada una puede fallar por su cuenta. Un navegador que inició sesión perfectamente no le dice nada sobre ninguna de ellas.

Mantenga ambas mitades en una sola línea temporal, pero puntúelas por separado. Así un solo ticket puede decir qué mitad se rompió sin convertirlo en una discusión sobre la propiedad.

Tome la entrada de la org de la org, no de la memoria

El flujo web toma una URL de instancia y guarda el resultado bajo un alias, y ambos valores deberían venir del propietario de la org en lugar del historial de terminal de un colega. Un host de sandbox copiado de un ticket antiguo es una causa común de un inicio de sesión que se autentica contra la org equivocada y luego falla en cada consulta.

Use la forma que documenta el complemento instalado, con su propio host y alias aprobados. Esa documentación es la referencia para los indicadores que cambiaron entre sfdx y la CLI actual.

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

El nombre de host y el alias de arriba son ejemplos, no valores predeterminados que deba copiar. Complete los pasos normales de identidad del navegador y de MFA en lugar de sortearlos con scripts, y nunca coloque una contraseña, un identificador de sesión o una semilla de autenticador en un comando de shell para saltarse el aviso.

Qué demuestra la autorización en caché

Un alias que aparece en la lista de autorizaciones local demuestra que un inicio de sesión tuvo éxito una vez en esa máquina. La lista se lee del almacenamiento local y no contacta con la org para confirmar que el token sigue funcionando, así que una entrada de aspecto saludable y una llamada a la API rechazada pueden ser ciertas a la vez. Trate la caché como un registro del pasado, no como una prueba de conectividad en vivo. Una comprobación de la caché responde a una pregunta de soporte, pero nunca cierra una investigación de conectividad.

La misma distinción se aplica a la sesión del navegador. Una pestaña que todavía muestra la org no significa que el token almacenado de la CLI coincida con la política actual, porque la vida del token, las restricciones de IP y las reglas de la aplicación cliente se aplican en el límite de la API.

Lea el registro local antes de borrarlo, ya que el alias y el host de la org son los dos datos que pedirá soporte. Eliminar un alias es reversible, pero eliminar el equivocado en medio de un incidente solo añade un segundo problema.

Dónde se rechaza realmente la solicitud a la API

Siga una solicitud de principio a fin y anote qué componente responde. Un fallo de TLS nombra un problema distinto de un 403, que nombra un problema distinto de un tiempo de espera, y el tiempo de espera es el único de los tres que apunta al túnel como primer sospechoso. Leer la clase de error antes del mensaje ahorra muchas conjeturas. Anote la clase antes de volver a ejecutar nada.

Las restricciones de dirección de origen son el caso que produce un inicio de sesión que funciona y una consulta que no, porque el flujo del navegador y la llamada a la API pueden salir por direcciones distintas. Arreglarlo con una lista de permitidos más amplia es una decisión del propietario de la org, no una comodidad, y debería ser el rango más pequeño que cubra el host.

Capture el comando que falla, el alias, el host de ejecución y la marca de tiempo, y deje el token fuera de todo lo que pegue en el ticket. Ese resumen de cuatro líneas es lo que el propietario de la org necesita para comprobar su lado.

Compruebe el flujo desde el host que lo va a usar

Pruebe desde la máquina que ejecutará la carga de trabajo. Un inicio de sesión verificado en su portátil no dice nada sobre un agente de compilación en otra zona de red, y la diferencia es exactamente lo que intenta encontrar.

Use una lectura autorizada inofensiva para la comprobación, y quédese con el primer error si falla.

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

Cuando el inicio de sesión tiene éxito pero la consulta falla, los candidatos restantes son DNS, enrutamiento, interceptación de TLS y política de cliente por parte de la org, y cada uno tiene su propio dueño. Cuando falla el propio inicio de sesión, el navegador y la CLI probablemente no están en el mismo host, y la corrección pertenece a la configuración entre ellos y no al túnel. La automatización recibe una regla más: un trabajo sin supervisión necesita un inicio de sesión aprobado basado en certificado, porque una sesión interactiva en caché copiada a un worker no es un diseño de identidad.