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.