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