Hello, I would like to make proxy_auth helper request fields configurable by adding a new request_format option to auth_param. Here is a sketch:
auth_param basic program ... auth_param basic request_format "%username %password %myportname" The actual %macro names in request_format should come from logformat codes where available (and we can add new ones where needed). I used more readable names for illustration purposes only. This feature is needed for Squid admins that have to use different internal authentication lookup algorithms(*) depending on various transaction parameters. For example, they may need to use Digest helper algorithm#1 for users coming to http_port#1 and Digest helper algorithm#2 for users coming to http_port#2. Or, perhaps, Basic helper algorithm#1 is for users with client SSL certificates signed by CA#1 while Basic helper algorithm#2 is for users with certificates signed by CA#2. There are many variations on this theme. Today, Squid supports only one authentication helper per authentication scheme. The need for multiple helpers per scheme can sometimes be supported by running several Squid instances, but parameters such as CA name or IP ranges do not allow for that workaround (or the workaround demands too many Squid instances to be practical). AFAICT, the proposed feature is 100% backwards compatible, generally useful, and not intrusive. There is one problem though; it surfaced during IRC discussions with Amos (thank you!). For example, consider authentication helpers that need http_port name as a parameter. The feature described above will supply those helpers with the required port information, and Squid will cache authenticated user credentials as usual. However, it may be wrong for a user coming in on port B to match Squid-cached credentials of a user already authenticated on port A, even if both user names and credentials are identical (e.g., both are called Bob and both use "letmein" as a password). Cache invalidation is also possible if Bob on port B is using a different password than Bob on port A, I guess. This credentials cache collision problem does not apply to all deployment scenarios, but sometimes those users must be segregated for authentication to work correctly. To address this, we add an optional request_realm parameter that tells Squid [how] to segregate users when caching authenticated credentials: auth_param basic request_realm "%myportname" The above instructs Squid to index its cache using (%myportname, %username) pairs instead of the default %username value, essentially. In most cases where request_realm is needed, it will simply contain the custom request_format part(s). However, I think the two should be configured separately because * We need a configuration knob to disable request realms anyway. * We will have to place unnatural restrictions on request_format syntax. * It is quite possible that, with some helpers, certain input parts should not affect credentials caching at all. * The feature may be later augmented with ACLs to group large set of values such as individual client IP addresses into compact request_realms such as /16 networks. [ Another alternative I considered was to add %macro support to the existing [Squid] realm parameter and use that instead. I do not think that is such a good idea because some authentication schemes do not have Squid realms, and also because Squid realm strings are shown to users and may not be appropriate for storing low-level details such as port numbers or IP networks. ] It is possible that, despite documentation warnings, some admins will misconfigure this, creating huge but pointless authentication caches and/or overloading their helpers (e.g., by specifying "%current_time" as the request_realm). I think that risk is acceptable. We cannot offer powerful features without also giving an admin the ability to shoot himself in the foot. Are there any objections to adding this feature? Any improvement ideas? Thank you, Alex. P.S. It is also possible to implement a similar but different feature where the selection of the helper is controlled by an ACL while the helper does not receive any extra information from Squid. This will not help admins that have to supply additional (and/or highly varied) information to helpers, so I am not discussing that feature here. The two features can coexist though. (*) I am talking about "different internal authentication lookup algorithms" for the _same_ authentication scheme (Basic, NTLM, whatever). This feature does not change how the HTTP client and Squid negotiate the authentication scheme to use. For simplicity, you may assume that the scheme is always Basic authentication (or always NTLM).