httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Resolved (sort of): Struggling with AuthMerging
Date Sat, 03 Aug 2013 17:15:45 GMT
Am Freitag, 2. August 2013, 23:05:09 schrieb Ben Reser:
> If all of your authz/authn providers are using the CONF flag and
> you're getting duplicated authz processing for subrequests that have
> the same conf applied to them then it's possible there's a bug
> here. I haven't ever specifically looked at this code so I can't
> tell you how it works, all I can do is tell you what the
> documentation says it does.  Unfortunately I have other priorities
> right now so I don't really have the time to go down that rabbit
> hole and find out if there is a bug that's causing extra authz
> calls.
> 
> Any attempt to optimize when authn/authz happens on subrequests is
> going to have to be done very carefully since you really can't make
> any assumptions about what should be allowed.  I realize that in
> your specific case that seems absurd but the httpd core code
> supports use cases that are very different from yours.

The AP_AUTH_INTERNAL_PER_CONF / AP_AUTH_INTERNAL_PER_URI switch has a 
design flaw in that modules cannot decide which flag to use 
dynamically, depending on the modules' configuration. Instead, if any 
module using AP_AUTH_INTERNAL_PER_URI is loaded, httpd will call the 
auth hooks for every URI, even if the respective module is not enabled 
by configuration. It would be much better if that flag was a runtime 
setting that could be switched on only if needed, on a per vhost 
basis.

AFAICS, the only module shipped with httpd that uses 
AP_AUTH_INTERNAL_PER_URI is mod_log_debug, where I have assumed that 
the ability to inject trace messages for every subrequest is more 
important than performance. Not sure if that was a good idea.

Do you have mod_log_debug loaded? If yes, try if things change if you 
don't load it.


Mime
View raw message