[cgiapp] CAP::Authentication not working properly with CAP::Session

Bradley C Bailey cgiapp at brad.memoryleak.org
Thu Nov 20 12:11:43 EST 2008


Richard,

> Hope someone can help with this. I'm having a major headache with 
> authentication and sessions.
> 
> With authentication configured to use STORE => Cookie I can login & out 
> OK, but each request generates a new CGISESSID, even when logged in. 
> When I switch to STORE => Session, I cannot login at all, but get 
> bounced back to the login page. The sessions table remains empty. The db 
> access is working ok as I get invalid login message and login attempt 
> 1,2,3, etc if I enter incorrect username or passwd, so it must be 
> reading the users table ok.
> 
> I have several other apps which works perfectly with CAP::Session and 
> CAP::Authentication, and I can use the session_config and anthen_config 
> settings interchangeably between apps, but the 'working configs' do not 
> make the current app. use sessions properly. All modules (CGI::Session, 
> CGI::Application, CAP::Session, CAP::Authentication) are current. There 
> is obviously something about the current app that is different to the 
> others, but I cannot see it.
> 
> In the CGI::Session docs there is a mention of session->flush, and if I 
> use this in teardown(), then sessions do start to work, providing I use 
> $self->session_delete after logout. Odd because I've never had to use 
> session->flush before.

What kind of environment are you using?

Sessions are supposed to automatically flush() when they go out of scope 
and are DESTROYed.  I have never had to explicitly call flush().  If you 
are using some kind of persistent environment (ie: mod_perl, FastCGI, 
...) make sure something isn't keeping the session around.


> But I'm also trying to use CAP::Flash, and find the flash message never 
> gets written to the session (even though flash->dump shows it's present 
> in the flash object), unless I use flash->flush in teardown(). But then 
> the message gets converted to 'keep' and never goes away.
> All this suggests to me there is something wrong with the way 
> CGI::Session / CAP::Session is working, but I can't put my finger on 
> anything obvious, after several days trying. Does anyone recognise this 
> behaviour or can explain it?

Probably related to the same issue as above, with objects not going out 
of scope and getting cleaned up.

Flash->flush() is a bit different than session->flush().  If you really 
need to put this code in teardown(), first call flash->cleanup() then 
flash->flush().  cleanup() goes through and marks data for removal, 
flush() writes it to the session.  This is all supposed to happen during 
DESTROY() as though, so it should be unnecessary.

Also, just curious, if you take CAP::Flash completely out of the picture 
does your session problem go away?


Regards,
Bradley C Bailey



More information about the cgiapp mailing list