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
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
