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

On 11/15/2013 08:11 AM, Amos Jeffries wrote:
> On 30/10/2013 5:13 a.m., Tsantilas Christos wrote:
>> The attached patch add the "auth_param request_format" and "auth_param
>> request_realm" to proxy authentication schemes.
>>
>> The request_format value used to define the format of the helper request
>> line. It is a "quoted string" with logformat %macro support. A new
>> %credentials macro can be used to supply user password and other
>> scheme-dependent information to the helper.
>>
>> The request_realm is an authenticated users cache key format, needed
>> when request_format feature is used to authenticate different users with
>> identical user names (e.g., when user authentication depends on http_port).

> I dont think the idea made it out of the IRC planning discussion properly.

There was a detailed RFC posted after the informal IRC discussion. The
RFC email date is October 10, 2013. It is rather unfortunate that your
objections come so late. The primary purpose of RFCs is to prevent the
waste of resources and confusion related to changing the primary
functionality of the developed, tested, and often deployed features!

> We need only _one_ format called realm_format.

In other words, you want to restrict the proposed request_realm to its
proposed default value, eliminating the need for an explicit
request_realm configuration option, right?

Here is the proposed request_realm default, quoted from the patch:

> + "request_realm" format
> + Specifies a custom format for the authenticated user cache key.
> + ... By default, Squid
> + uses request_format as request_realm.

Please note that here I am asking about the essence of your "_one_
format" objection, not about the new option(s) names ("realm_format" is
not a good name choice but we can discuss that minor detail separately)
and not about restricting request_format values (which is a separate
topic discussed below).

> The parameters sent to the helpers today are essentially mandatory for
> those schemes validation process to operate correctly. The auth helpers
> are semantically a validation API. The possibility of sending other
> details to widen the authentication space around that validation is an
> optional extra, not a replacement for any one of the mandatory parts or
> the validation itself.
> So we can add, but not allow subtraction from the details arleady sent

I am OK with prohibiting the admin from subtracting (until there is a
valid use case to relax that restriction). AFAICT, it means adding more
code to police configured values (in hope to prevent an admin from
misconfiguring their Squid).

Thank you,

Alex.
Received on Fri Nov 15 2013 - 17:14:11 MST