Gary Buhrmaster <gary.buhrmas...@gmail.com> writes:
> Russ Allbery <ea...@windlord.stanford.edu> wrote:
> ....
>> I'm not yet sure when all this will happen, since I'm actually supposed
>> to be working on other projects now. :) But I wanted to mention all
>> of this to let people know about the current situation, and also to see
>> if people have any other preferences for how this should work.
> It would depend on the definition of "long term", but if 'require
> webauth' is reasonably RSN, I would rather see that than setting
> request_rec.user to an empty value, and documenting that Apache 2.4 does
> not yet properly implement WebAuthOptional, based on the principal of
> not allowing (potential) access to (potentially) restricted content.
> Alternatively, at least make setting the value to null require some
> other setting (like "INSECURE_WEBAUTHOPTIONAL_ENABLED" :-)
My original message was wrong in that require webauth will still require
request_rec.user be set to something, such as the empty string, since the
Apache core now rejects authentication modules that return success but
don't set request_rec.user.
On the other hand, I think I found a better solution to this. I should be
able to process optional authentication in the fixups hook, which means
that I won't need any sort of require directive after all and won't have
to set request_rec.user. Just using:
AuthType WebAuth
WebAuthOptional on
require all allowed
should work with Apache 2.4 even when the check_user_id hook is bypassed
completely. However, the code is a bit complicated; I started working on
it, but it may take me a bit to finish it.
I'm reluctant to break everyone's WebAuthOptional Apache 2.2
configurations on upgrade to 2.4, though. If I don't add the empty user
workaround, anyone who is currently using Apache 2.2 with require
valid-user and WebAuthOptional will have their configuration break on
upgrade. I guess I don't have a good feel for how big of a deal that is.
--
Russ Allbery <ea...@windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
