Randal L. Schwartz wrote: >>>>>>"Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes: > > > Geoffrey> if I understand the problem correctly (which I may not) I > Geoffrey> think both those phases are probably wrong and a more > Geoffrey> generic phase is probably best, like the PerlInitHandler. > > Actually, now that I think about it a bit more, the question is "can > this specific person access this resource? If not [first visit, for > example], do something else" > > So it's really an Authz question. And it should be handled by an > internal redirect if the authz fails. You want it *after* trans, > access, and auth, so that you can determine resource, host-based > permission, and identify the individual.
I think you have a point, but that it all really depends on your requirements. typically one uses access phase for authentication based on non-user credentials, such as ip address, browser type, etc. for authen it's typically user-provided credentials, such as username. now, I suppose that something like Apache::Motd could fall into the authen category, since it assigns each "user" (a browser, not a person) a cookie which is used to later identify the user and ultimately decide whether the user requires some popup page. and sure, you would probably want to use the authz phase for that. but there is also just reason to use the access phase, since the real user hasn't proactively done anything to distinguish himself. however, I'm not so sure that this particular example fits that model very well - authz won't even run if you don't have a Requires directive, which feels kind of limiting. that is, do you want to waste your authen and authz phases on a simple popup? don't forget that the first authen and access handler to return OK wins, so you only get one chance to validate your user - if you choose to use that for a popup manager then you can't really run _real_ authen/authz against that user. at least not easily that I can see. anyway, this is all probably academic, since I'm not really implementing anything and probably can't see the big picture as a result. but it is interesting to talk about :) --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
