Re: [squid-users] Force Basic auth for Java applets

On 18/03/11 05:21, Marco Beck wrote:
> Hi Amos,
>
> On Thu, Mar 17, 2011 at 12:49:20AM +1300, Amos Jeffries wrote:
>>>
>>> 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.
>>
>> AFAIK header_replace has only ever worked on request headers passing
>> through to some external server.
>
> No, in Squid 2 it also works for (Squid generated) reply headers,
> we use this on our production servers as described.

Oh. Thanks for that.

>
>> You want reply_header_access with the same logic to strip away
>> "Proxy-Authenticate: NTLM"
>
> Yeah, but reply_header_access only allows filtering by header name,
> not header value, AFAIK.

It filters by name. But the filter do/don't is determined by the ACLs.
An ACL testing for header content regex should only let the Basic ones out.

This for example should work to allow only basic auth advertised:
  acl javaauth rep_header Proxy-Authentication ^Basic
  acl java browser ^Java
  reply_header_access Proxy-Authentication deny java !javaauth

The header stripping is done on a line-by-line basis, so for multi-entry
headers like auth which Squid does not combine together it should be
selective.

>
>> 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.
>
> This sounds nice. But there are probably other use cases where
> replacing reply headers could be useful. The small patch* attached
> introduces a new config file option 'reply_header_replace' to do
> this. This gets our old workaround working again.

Yes, agreed. Thank you for the patch.

>
> To be consistent with the naming change of header_access in Squid 3,
> header_replace should be renamed to request_header_replace, I think.
> I'd be glad to send patches, if you're interested.

Yes it should. That can be rolled into the same patch submission.
It's enacted trivially by:

-NAME: header_replace
+NAME: request_header_replace header_replace

(with appropriate text description updates of course).

>
> Thanks,
> Marco
>
> * Created with 'bzr send'; never used bzr before, so I don't know
> if this is the usual way to send patches around...

For us it is accepted, merge/send or diff patches.

Just needs to go to the squid-dev mailing list with an appropriate
commit message. This type of bzr merge patch needs a [MERGE] on the
subject line for the automatics.

I've done the audit part for this, looks fine. I'll port this back to
3.1 stable as a regression fix, so the
doc/release-notes/release-3.1.sgml file also needs updating as part of
the patch (ignore the .html).
  Specifically; adding header_replace entry under changed config options
to say its deprecated by request_header_replace. Along with entries for
the two new names under added config options.

Cheers.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.11
   Beta testers wanted for 3.2.0.5