Autenticación Basic preventiva do proxy para un punto final coñecido

Un cliente que espera o desafío primeiro agarda a que o proxy o pida. Un cliente Basic preventivo xa coñece o punto final seleccionado e envía a credencial na súa primeira petición aplicable. Eliminar ese intercambio pode ser útil. Segue a ser unha decisión sobre a onde vai un contrasinal.

Coñeza o punto final antes da optimización

Un proxy privado fixo cunha política de autenticación coñecida é un caso máis claro ca unha capa de encamiñamento que pode escoller un intermediario descoñecido. Vencelle a conta á identidade e ao protocolo esperados do proxy. Non constrúa un callback xenérico que responda a cada desafío cun único contrasinal corporativo.

Basic leva unha representación base64 da conta, non unha proba cifrada. TLS ata o oínte do proxy é unha elección de conexión distinta da sesión HTTPS do sitio. O túnel HTTPS do sitio non protexe retroactivamente unha credencial Basic enviada por unha conexión cliente-proxy sen cifrar. Unha LAN privada é unha localización, non unha propiedade de cifrado.

Manteña o mecanismo específico

O Basic preventivo non é un atallo universal para Digest, NTLM ou Negotiate. Eses mecanismos teñen os seus propios requisitos de intercambio. Un cliente que descobre esquemas admitidos pode realizar transaccións adicionais de forma lexítima.

Use a interface de autenticación de proxy da biblioteca escollida e despois inspeccione o esquema e o alcance efectivos. Un axuste de preautenticación de destino pode non controlar o aperta de mans do proxy. Unha conexión autenticada existente tamén pode ocultar se unha conexión nova realizaría un desafío.

Compare a operación completa: número de intercambios, tempo de finalización, protección de transporte necesaria e comportamento cando cambia o proxy. Un rexistro máis limpo só é útil se a aplicación segue autenticándose co intermediario previsto e se detén cando ese acordo non se pode establecer.