|Summary:||AuthzProviderAlias ignoring all Require-Parameters except first one|
|Product:||Apache httpd-2||Reporter:||Hank Ibell <hwibell>|
|Component:||mod_authz_core||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|OS:||Mac OS X 10.1|
|Attachments:||Proposed patch for trunk|
Description Hank Ibell 2018-06-18 15:00:05 UTC
AuthzProviderAlias only accepts the first Require-Parameter even if more were provided. A contrived example where this could be an issue is if a user had defined a list of blacklisted IPs, such as the following: <AuthzProviderAlias ip blacklisted-ips XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY> </AuthzProviderAlias> <Directory "/home/hwibell/2.4.x/built/htdocs/test"> <RequireAll> Require not blacklisted-ips Require all granted </RequireAll> </Directory> In the above example, clients with the IP XXX.XXX.XXX.XXX would be correctly denied access to anything in `/test` while clients from YYY.YYY.YYY.YYY would be able to access it when they shouldn't.
Comment 1 Hank Ibell 2018-06-18 15:00:36 UTC
Created attachment 35971 [details] Proposed patch for trunk
Comment 2 Christophe JAILLET 2018-06-19 19:43:42 UTC
Hmm, I think that the proposed patch would break configuration like: <AuthzProviderAlias ip blacklisted-ips "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY"> </AuthzProviderAlias> Not sure if such configuration is used, but it would be a workaround to the issue you have spotted. Would it be enough to just explain in the doc that if several Require-Parameters are needed, they have to be put between some "? https://httpd.apache.org/docs/2.4/en/mod/mod_authz_core.html#authzprovideralias Otherwise, your patch should be improved to remove the ", if and only if it is found at the start and at the end of the 'Require-Parameters' string.
Comment 3 Hank Ibell 2018-06-20 15:26:00 UTC
@Christophe You are right: quoting the Require-Parameters works, and the patch would break such configurations. I think ditching the patch and adding a note to the doc makes sense. Thanks for catching that. :)
Comment 4 Christophe JAILLET 2018-06-23 14:19:30 UTC
Message added in doc. Warning log message also added if such a case is detected at run-time. See r1834209.