On 5/15/19 8:42 AM, André Warnier (tomcat) wrote: > (In any case, it does /not/ call the perl AuthzProvider again). > (That is not really what I want; I'd like it to call authz_user()
Apache doesn't work that way. Everything you've described is basically just how things work in 2.4. your authz_user() will be called (up to) two times. 1. Before authentication where $r->user is not set. The purpose of this is to allow you to handle *anonymous* authorization. You can return AUTHZ_GRANTED here and no authentication will happen at all I believe. 2. Or, you can return AUTHZ_DENIED_NO_USER, which will trigger authentication, and *only if that succeeds*, will your authz_user() be called a second time. > anyway, and let authz_user() decide what happens next). Yeah, Apache just doesn't work this way. The only way to hack this that I can think of is for you to set something in $r->user that indicates that the authentication failed and authz_user could figure out what went wrong in the second call based on the value of $r->user. That's all you have to go on. You might even be able to use pnotes() to stash away extra stuff you need, but this feels like a horrible hack IMO. It's not particularly clear to me what "let authz_user() decide what happens next" means in this context. If authorization fails, typically you would just return an error code such as Apache2::Const::SERVER_ERROR. If it was successful, and the user is valid, you'd return Apache2::Const::OK. Otherwise you would typically return Apache2::Const::UNAUTHORIZED. If you to customize what is displayed for those messages, typically you use $r->custom_response() (see Apache2::Response). In today's times, when compared to modern alternatives like Plack/PSGI, this all feels very cumbersome and antiquated IMO. Regards, Michael Schout
