Interceção do Squid versus autenticação de proxy explícita
Explique por que a autenticação de proxy explícita comum não pode simplesmente ser adicionada a um ouvinte de interceção do Squid.
Um cliente de proxy explícito sabe que está a falar com um proxy. Um navegador intercetado pensa que se ligou ao sítio web. Essa diferença é central para a autenticação.
A autenticação de proxy normal usa um desafio de proxy e uma resposta de autorização de proxy. Um cliente que não escolheu um proxy não deve enviar levianamente credenciais de proxy a um intermediário inesperado.
Por isso, a orientação de interceção do Squid não suporta simplesmente combinar proxy_auth com o modo de interceção. Um auxiliar de autenticação Basic a funcionar não altera aquilo que o navegador considera ser o ponto final remoto.
Se os utilizadores identificados precisarem de um proxy de reencaminhamento autenticado normal, configure os clientes explicitamente, quer diretamente, quer através de uma configuração de proxy gerida adequada. Mantenha esse ouvinte e a sua política de autenticação separados de um ouvinte de interceção.
Um portal de autenticação, um sistema de identidade ao nível da rede ou uma disposição de interceção TLS são outro desenho com requisitos de confiança e implementação diferentes. Não é uma reparação de uma linha para a troca de proxy explícito em falta.
Não resolva a ausência de um pedido tornando o serviço intercetado público ou permitindo todos os clientes. Primeiro decida se o requisito é autenticação explícita de utilizador ou interceção de tráfego que nunca foi configurado para um proxy. Ambos exigem pressupostos diferentes.