Adam Prime wrote:
http://perl.apache.org/docs/2.0/api/Apache2/SubRequest.html#C_internal_redirect_
Thanks. Although considering Torsten previous answer and explanation, that's kind of an odd place, no ? ;-) [...]
It seems odd to me to set $r->user in an AccessHandler. It's probably not a problem, but it seems (at least to me) that that would make more sense as a part of the Authen code. You can then control all your 'second chance' stuff with normal state checking within your Authen Handler instead of doing funky stuff with set_handlers (which seems to be what you're doing)
Well, yeah, I guess it can be debated, on the philosophical level. Access Control is supposed to be allowing or denying access, based on criteria other than the user identity. This handler does 2 things : It checks the remote IP of the caller, and can deny access if it is not in its list. That's clearly part of Access. Now in addition, if the IP is in it's list, it can have a "standard" user-id associated with it. So, as long as we're there, we might as well pick it up and set it in $r->user. The Authentication runs right after it, and that's another handler. This one is supposed to check that we know who the user is. It does that, by checking first $r->user. If it finds it there, it means that something put it there before, and it this case that can only be the Access handler. If the Access module did not put it there, then this handler would have to re-read the IP list, and look again for the caller IP, which does not seem to make sense. Now if there is no $r->user, it means the user needs to login. For the login, we want to send back a nice-looking form. And after the user fills it in, we would like - if the user-id is ok - to proceed back to the original page that the user tried to access. For that we need to fill-in some parameters in the login form, so that when the user posts it, we know where to go (back) to. That's where the set_handlers kicks in. Instead of sending an external redirect to the browser toward a static login form (which I could then not fill in), or to a server location where they would get the login form (which would nean another <Location> section in the configuration, and another browser round-trip), I thought it was more elegant and mod_perl-ish and not so funky, to use set_handlers() to install a ResponseHandler for the current call, and then return OK from the current Authen handler. The next phase is the response (I'm skipping the AuthenzHandler for clarity). Now we have two cases : - either the access/authentication/authorization was ok, and we have the default Apache handler sending the normal response - or the AAA was not ok, and we have the custom previously-installed perl ResponseHandler, who will send the login form, while filling it in on the way based on information stored in $r->pnotes previously. Without a browser round-trip. I personally find this rather elegant, and not too bizarre. It also works very nicely, in most cases. The problem is that, if the location desired by the user originally already has a non-default handler, then things don't happen exactly as I wanted : despite installing modperl as the handler and my ResponseHandler under that, the original Apache-level handler is still being called. But that's another thread on this same list.
