Re: redirecting outside the Content handler
> > $r->set_handlers('PerlHandler",\&My::Package::handler);
>
> set_handlers() should work. keep in mind that it's current not
> possible (IIRC) to set_handler() for the current phase. so, for the
> PerlHandler you'd want to do it from someplace else, like your
> PerlAccessHandler or something.
Which is ideal for me, since I'm trying to set it in the
PerlAccessHandler
> oh, and the syntax doesn't require a coderef -
>$r->set_handlers(PerlHandler => 'My::Package');
> works too.
Each of these:
$r->set_handlers(PerlHandler => 'My::Package');
$r->set_handlers(PerlHandler => 'My::Package::handler');
$r->set_handlers(PerlHandler => \&My::Package);
$r->set_handlers(PerlHandler => \&My::Package::handler);
give me:
[error] Can't set_handler with that value
Any ideas?
(I've also tried the same variations on
$r->set_handlers(PerlHandler =>
'Apache::ROOT::path::to::myscript_23pl');
to try and convince it to load my Apache::Registry scripts, with the
same results
)
Re: redirecting outside the Content handler
"Narins, Josh" wrote:
>
> I think I know this one.
>
> #you might want to do this line, for edification if nothing else
> my $list_ref = $r->get_handlers("PerlHandler");
>
> $r->set_handlers('PerlHandler",\&My::Package::handler);
Excellent! Thanks. One associated question: Is it possible to
manipulate things such that I'm calling an Apache::Registry script? I
can make a handle to redirect, but I'm sure that isn't necessary. The
Eagle book only mentioned direct handlers.
redirecting outside the Content handler
I have a few AccessHandlers that I'd like to redirect the user to the correct page to get access if they don't have it. I tried ErrorDocuments, but I have multiple layers of authentication, and ErrorDocuments won't cascade. So I'm looking at switching the ContentHandler. internal_redirect() won't work, since it only works as intended inside the content handler. Can I just override the currently expected ContentHandler? How would I do that?
Stacking ErrorDocuments OR multilevel PerlAccessHandler
Once upon a time there was a project that required a PerlAccessHandler and form-based login. This project lived in the land of mod_perl, so it lived a happy life, with a setup something like: PerlHandler Apache::Registry SetHandler perl-script Options +ExecCGI PerlAccessHandler My::EnforceLogin ErrorDocument 403 /not-protected/login.pl?rm=Bounce PerlHandler Apache::Registry SetHandler perl-script Options +ExecCGI (/not-protected/login.pl is a CGI::Application-based script, which is why I'm using Apache::Registry) This solution worked fine, and the project was a happy creature. Then one day the project decided to expand to include a second layer of authorization. Now users fell into three groups: No requirements, login required, and logged-in-as-confirmed user. (Any logged in user can become a confirmed user (a one time process) by going through a series of steps, held at, say, /requireslogin/confirm.pl. Thus, you must be logged in before I can check that you are confirmed, but a logged in user may or may not be a confirmed user) I, as caretaker for the innocent little (if growing) project, wanted to add a second access handler. The thought was that /requiresconfirm/ could use the same My::EnforceLogin as /requireslogin/ as well as My::EnforceConfirm. The ErrorDocument would bounce the user to /requireslogin/confirm.pl, and if they weren't logged in, it in turn would bounce them to /not-protected/login.pl I thought this a solid and clever answer, with nice modular little bits, and full code reuse. Sadly, I am not as clever as I thought (again), because a 403 on a 403 (as happens if a non-logged-in user tries to access /requiresconfirm/) doesn't bounce twice but drops to the generic handler. So now I have a few options, and I'm not sure what is the best way to go about this. I've tried using an AuthenHandler with a different ErrorDocument to handle it, but AUTH_REQUIRED began negotiations with th e browser -- undesirable. I could make my handlers do internal redirects (a new task for me). I could do external redirects. I could ask you folks if what I originally intended can work just fine with some minor magic change. OR I could just toss code reuse out and make My::BloatedandRepetativeHandler to check for both. The Cookbook and the Eagle book, so far as I've discovered, don't cover cascading errordocuments. (at least in the Auth* chapters) So I thought I'd check -- I can't be the first (or 1000th) to have this issue, how is it normally handled?
Attempting persistence
I'm looking at converting a large CGI installation over to mod_perl. The code is clean, so moving it to Apache::Registry isn't causing any problems, but I'd like to get the most bang out of the conversion that I can. Currently the code is a set of scripts that all call modules that are subclasses of a local subclass of CGI::Application (I realize the subclassing is hitting our efficency, but it's deemed worthwhile for the advantages it brings). These modules have run-modes as per standard CGI::App, and return to CGI::App a scalar ref of HTML, which CGI::App outputs with the appropriate headers via CGI.pm. The scalar ref our modules return are content files processed through a Template Toolkit template. I'm seeing the following potential areas of speed improvements: - CGI::App could be altered to use Apache::Request. I haven't looked into the code yet, but I recall from previous scans that it isn't overly complex (the beauty is in the simplicity, after all), so if the efficiency is worth it, and if CGI::App can't be easily coaxed into it, I should be able to fork my own to do Apache::Request. Of course, I'm doubtless not the first to consider this, so has someone already invented this wheel? - My Template Toolkit object could be reused, along the lines of Apache::DBI. (Since that object isn't changed in any session, just processes some data and returns a result). Sadly, I'm not clear on how to do this. Apache::Template is a handler in it's own right, so it won't do what I seek. Should I jump into Apache::DBI to see how it does it, or is there some documentation on how to create persistant objects that survive between connections? [Actually, I want more than a persistant TT2 object, since I have a wrapper module that has some helpful interface routines, so I'd want that to be persistant as well.] I've looked at perl.apache.org and skimmed the eagle book without finding this, but it is a bit specific, so I could have missed it. Thanks in advance for any help.
