Re: [PATCH] Add auth_param request_format, request_realm to proxy authentication schemes

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).

The question of keeping KK and similar credentials "type" labels in
%credentials values would remain open only if we we keep %credentials
functionality, of course. If Christos yanks that support from the
proposed patch, hard-coded request generation will continue to insert KK
and other types where and when they are needed.

> 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).

> 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.

HTH,

Alex.
Received on Tue Nov 19 2013 - 19:11:13 MST