Chris Robertson wrote:
> Amos Jeffries wrote:
>> Sander, Andreas wrote:
>>> Hello,
>>>  
>>> I am using Squid 2.7Stable6. I have an external helper that shall
>>> obfuscate the authenticating user for a cache_peer. Unfortuantely this
>>> does not work in any condition:
>>>  
>>> Lets take an example where my helper returns:
>>> OK user=hello password=world
>>>
>>> Example 1:
>>>  
>>> auth_param ...
>>> external_acl_type groupbuilder children=1 %SRC %DST
>>> C:\temp\helper\Debug\helper.exe
>>> acl special external groupbuilder
>>> http_access allow special
>>> cache_peer 192.168.1.101 parent 3128 7 no-query default login=PASS
>>>
>>> In this example the user "hello" is used for authentication when passing
>>> the request to "192.168.1.101". Unfortunately the user is not
>>> authenticated.
>>>
>>>
>>> Example 2:
>>> auth_param ...
>>> external_acl_type groupbuilder children=1 %LOGIN %SRC %DST
>>> C:\temp\helper\Debug\helper.exe
>>> acl special external groupbuilder
>>> http_access allow special
>>> cache_peer 192.168.1.101 parent 3128 7 no-query default login=PASS
>>>
>>> In this example, always the authenticating user, which is authenticated
>>> by "auth_param" is passed to "192.168.1.101". The result of the external
>>> helper is ignored.
>>>
>>> What can I do to modify a login name by an external helper?
>>
>> You cannot.
>>
>> login=PROXYPASS simply passes the authentication headers the client 
>> sent without changing.
>>
>> login=PASS does the above, but when the client did not send any such 
>> header it may _add_ a Basic auth header using the external helper 
>> details.
>>
>> login=<username>:<password> does not pass anything, it uses the values 
>> from squid.conf on every request.
>>
>> login=*:<password> passes the client-given username through but 
>> replaces the password with the one in squid.conf on every request.
>>
>> This is the total of the login= features available in Squid 3.1 and 
>> older.
> 
>  From http://www.squid-cache.org/Doc/config/external_acl_type/...
> 
>     The helper receives lines per the above format specification,
>     and returns lines starting with OK or ERR indicating the validity
>     of the request and optionally followed by additional keywords with
>     more details.
> 
>     General result syntax:
> 
>       OK/ERR keyword=value ...
> 
>     Defined keywords:
> 
>       user=        The users name (login)
>       password=    The users password (for login= cache_peer option)
> 
> ...which indicates to me that if the external_acl_type returns the 
> keywords "user" and/or "password", those will be substituted for the 
> "real" credentials supplied by the client.  I have to assume the 
> original poster interpreted this documentation in the same manner.
> 
> Are we wrong?  If so, what does this documentation really mean?
They are to supply alternate values which _may_ be used for many 
operations after that point. Sometimes used sometimes not. I'm not sure 
of all the other uses.
The cache_peer usage is as I have stated above. Only sent in the absence 
of real incomming credentials from the client when login=PASS is used, 
login=PROXYPASS will not use them at all.
NP: there are a few other changes happening around this setting at the 
moment in Squid-3. So if we can spec out the behaviour needed it likely 
that it will be added.
Amos
-- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13Received on Sun Aug 09 2009 - 01:04:21 MDT
This archive was generated by hypermail 2.2.0 : Sun Aug 09 2009 - 12:00:03 MDT