[cgiapp] CAP::Authentication->redirect_after_login

Graham TerMarsch cgi-application at howlingfrog.com
Thu Jun 17 03:00:59 EDT 2010


On June 16, 2010, n1zero at aol.com wrote:
> I am using CA::Dispatch & CAP::Authentication in pretty much their
> out-the-box state. I have found that I get this to work only if I hack a
> line in CAP::Authentication, but I'd like to know why things don't work
> without the hack and what I should do to avoid it.
> 
> For apache I have
>     DocumentRoot /srv/trial/www/
>     PerlOptions +Parent
>     PerlSwitches -I/srv/trial/mod
>     PerlSwitches -I/srv/trial/lib
>     <Location /trial>
>         SetHandler perl-script
>         PerlHandler CGI::Application::Dispatch
>     </Location>
> so that the user hits /trial/mod3/page2 and this is dispatched to Mod3.pm
> in runmode page2. (This all works perfectly.)
> 
> In Mod3.pm I have
> __PACKAGE__->authen->protected_runmodes('page2');
> so that upon the above hit, the user is given the built-in login form.
> (This all works perfectly.)
> 
> But this is where it goes wrong.  When the user hits <Sign In> the post
> goes to /trial, which doesn't exist (in this example app).  Looking at the
> page of the form reveals it has action="/trial". That comes from
> CAP::Authentication, "my $action = $query->url( -absolute => 1 );", which
> gives in my case '/trial'.  Now, it turns out $destination is set
> correctly, so if I follow this with "$action = $destination" then it all
> appears to work perfectly.  I'm guessing this is a case of user error, but
> I can't see what I've done wrong to make $query->url give a
> less-than-useful value.

Hmmm... this sounds an awful lot like:

  https://rt.cpan.org/Ticket/Display.html?id=45019

where the "path_info" isn't properly set up if you're using URL rewriting via 
mod_rewrite, and as a result generated links thereafter aren't generated the 
way that you think they should be.

Although you don't say you're using mod_rewrite in your config, this sounds a 
lot like this problem (which I've experienced ever since CGI.pm changed its 
behaviour w.r.t. this).

Which reminds me... markstos... did you ever get any further discussion on 
this (and is it something we can ever hope to see fixed in CGI.pm)?

-- 
Graham TerMarsch
Howling Frog Internet Development, Inc.


More information about the cgiapp mailing list