On 2013-11-20 08:11, Alex Rousskov wrote:
> On 11/19/2013 02:54 AM, Tsantilas Christos wrote:
>
>> My understanding is that we need:
>> 1) Allow configuring the request format using one of the following:
>> a) Use a request_format configuration parameter plus the
>> %credentials formating code
>> b) Use the following request format:
>> [prefix] credentials [key_extras]
>
> Yes. And since the official code implements (b) already (without
> key_extras), it may be best to add key_extras processing to that code
> rather than to add [hidden] %credentials functionality. To avoid
> redoing
> this code for the third time, I recommend getting a clear answer from
> Amos first:
>
> Amos, do you want Christos to yank all internal support for
> %credentials
> macro, going back to the hard-coded generation of the credentials part
> of helper requests? Or are you OK with Squid supporting %credentials
> macro, and the patch using that internal support to generate the helper
> request? In both cases, the admin will not use %credentials in
> key_extras configuration (because credentials info will be
> automatically
> prepended by Squid in both cases).
I'm in two minds about the %credentiasl macro itself. It makes sens as a
separate thing for logging those details, or using in other helpers
formats (rewriter, exetrnal ACL, etc).
But it is definitely not necessary for what this patch needs to do, IMO.
If you want to omit it from this patch and do it as a second one that
would be okay.
The need for it would be quite rare, such as admin passing the helper
values used directly as SQL query parameters.
>> 2) A request_realm similar functionality to define a domain where the
>> the user is valid. If none defined the %request_format or the
>> %key_extras will be used.
>
> If I understand Amos' request correctly, request realm becomes
> %key_extras. There will be no request_realm option to change that
> hard-coded association (at least not during this project).
>
Yes. Exactly so.
>
>> I must note that the key_extras does not remove the need for the
>> request_realm.
>
> Right, but we can limit the initial official support to cases where
> request_realm is the same as key_extras. That is a common case AFAICT.
>
Agreed. We need *one* parameter to configure both strings.
Amos
Received on Tue Nov 19 2013 - 23:01:17 MST
This archive was generated by hypermail 2.2.0 : Wed Nov 20 2013 - 12:00:11 MST