Spoke too soon...
When I have:
external_acl_type propel_header_auth %{x-pun} /etc/squid/ident.pl
acl propel_auth external propel_header_auth
acl Authenticated proxy_auth REQUIRED
acl all src 0.0.0.0/0.0.0.0
acl internalblock dst 10.0.0.0/255.0.0.0
http_access deny internalblock
http_access allow propel_auth
http_access allow localhost
http_access allow Authenticated
http_access deny alleverything is allowed. It looks like the script is giving an OK even if the x-pun is not in the browser. What does squid pass to the ident.pl if there is no header x-pun?
I corrected it by changing
http_access allow propel_auth
to
http_access allow localhost propel_auth
but I would like to use this option without localhost.
Ryan Lamberton
----- Original Message ----- From: "Henrik Nordstrom" <hno@xxxxxxxxxxxxxxx>
To: "Ryan Lamberton" <ryan@xxxxxxxxxxxx>
Cc: "Henrik Nordstrom" <hno@xxxxxxxxxxxxxxx>; <squid-users@xxxxxxxxxxxxxxx>
Sent: Wednesday, May 11, 2005 7:40 AM
Subject: Re: [squid-users] external_acl_type with http request header question
On Wed, 11 May 2005, Ryan Lamberton wrote:
Thank you for your help. The perl script does work. I had:
external_acl_type propel_header_auth %{x-pun} /etc /squid/ident.pl x-pun
and the x-pun at the end of the external_acl_type was causing the problem. I wasn't sure why it was there but it caused the script to fail and took squid down with it.
Any data you have in the acl is sent after the format details. So in this case the input to your script send by Squid would have been
base64-encoded-username x-pun
I also added quotes around the username (OK user="username") just in case (I was not sure the @ character was allowed). So far all things are working great!
@ is allowed. It's only quotes, whitespace and \ characters you need to be careful with. If you use the 3.0 protocol then handling of "odd" characters is simplified by URL escaping.
Regards
Henrik
