Search squid archive

Re: Force Basic auth for Java applets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux