On 17/03/11 00:08, Marco Beck wrote:
Hi,
there is a known problem with certain Java applets (http(s) clients) when
using NTLM authentication (see e.g. [1]). In Squid 2 a widely adopted
workaround was to force basic authentication for those clients:
acl javaNtlmFix browser -i java
acl javaConnect method CONNECT
header_access Proxy-Authenticate deny javaNtlmFix javaConnect
header_replace Proxy-Authenticate Basic realm="foo"
I don't get this to work in Squid 3. The 'header_access' option
has been split into {request,reply}_header_access, and 'header_replace'
seems to have been changed to only apply to request headers.
Any ideas? I'm sure I'm missing something. I experimented with a
couple of other options, but without getting the wanted result.
Disabling authentication completely for Java applets isn't feasible
(security policy). I did find a couple of similar reports on the
mailing lists archives, but no solution AFAICT.
We're running squid3-3.0.STABLE19 on SLES10-SP1. We could easily
deploy custom RPMs built from e.g. a newer Squid version if there
is a known solution.
AFAIK header_replace has only ever worked on request headers passing
through to some external server.
You want reply_header_access with the same logic to strip away
"Proxy-Authenticate: NTLM"
I have plans to add ACL testing to decide which auth types get added to
the challenge headers in the first place. For exactly this type of
restriction. But have no time to code it myself anytime soon. If you or
anyone wants to do the work and test it I'm happy to advise and mentor
the coding.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.11
Beta testers wanted for 3.2.0.5
