A túa aplicación conéctase a un proxy no seu propio equipo. Ese axudante autentícase despois co proxy da empresa. Non é necesario que a aplicación realice por si mesma o intercambio de autenticación da empresa.

application → local helper → company proxy → destination

Un axudante como CNTLM ten configuración de conta e de proxy de orixe. O seu escoitador local ten unha fronteira propia de accesibilidade e de acceso. Un contrasinal de navegador introducido noutro punto final non configura automaticamente ningunha das dúas cousas.

Determina que salto fallou

Primeiro confirma que a aplicación escolleu o escoitador e o protocolo reais do axudante. Un erro antes de chegar a ese escoitador non é un fallo de NTLM. Despois comproba se o axudante chegou ao pai configurado e se o pai aceptou a súa identidade.

Un 407 devolto por esta ruta necesita atribución. Correlaciona a transacción local co diagnóstico redactado do axudante en lugar de supoñer que o estado visible identifica a conta que a túa aplicación debe enviar.

Os exemplos antigos ás veces engaden unha cabeceira keep-alive e informan de éxito. A persistencia pode importar na autenticación orientada á conexión, pero esa observación non demostra que toda configuración fallida de axudante necesite a mesma cabeceira. A selección do punto final, o método admitido, a conta e a vida da conexión seguen sendo entradas separadas.

O escoitador é un servizo real

Loopback mantén un escoitador fóra da rede circundante; non distingue todos os procesos nin usuarios dese equipo. Unha pasarela ou unha vinculación máis ampla cambia o conxunto de chamantes que poden usar a identidade de orixe do axudante. Fai ese cambio de forma deliberada.

Utiliza unha disposición de axudante aprobada cando a aplicación non poida realizar o esquema requirido. O resultado útil é un camiño coñecido cunha propiedade de conta coñecida, non un servizo extra sen explicación que por casualidade fai que unha descarga funcione.

Artigos relacionados