On Tue, 22 Mar 2005 17:15:26 +0200 (IST), Gabor Szabo <[EMAIL PROTECTED]> wrote: > I encountered two issues, I hope you might be able to help: > > 1) I noticed that ocassionally the login and the logout processes don't > succeed, that is, they run ok but the session data in the database > (I am using SQLite as the repository for the session data) is not > updated. More exactly I notice that the application thinks the login > process went ok but then when I visit the page again the user is > still not logged in. > > Adding $session->flush() at the end of both the login and logut process > seem to solve the problem but I thought this should be automatic.
CAP::Session leaves the updating to CGI::Session. CGI::Session is supposed to flush the data when the object goes out of scope. This usually happens when the CGI::Application object is destroyed at the end of a request. I usually find that when the sessions are not being updated, it has to do with a configuration issue. I expect it may have to do with the 'AutoCommit' flag in DBI. Do you have that set? The fact that it happens 'sometimes' makes it more difficult to solve, so this may not be the problem. > (I am using CGI, not mod_perl) You are not using SpeedyCGI (also called PersistentPerl) are you? That will have the same effects as mod_perl has. > 2) I have the a > $self->session_config call in cgiapp_init, setting a cookie for > every visitor right when they visit. While this might be good for > visitor tracking it actually adds quite a lot of rows in the database > for people who don't really need session management as they don't > log in. a call to $self->session_config should not create the cookie. That doesn't happen until the first call to $self->session. The session object is not created until $self->session is called for the first time, so $self->session_config would not know what to set the cookie to since it doesn't have a session ID yet. > To make the problem worse when the crawler of Google and friends come > I think they don't send back the cookie they get so for every > "page view" they generate they get a new cookie and a new row in the > database. As CPAN::Forum had nearly 8000 pages when it was opened > (for every CPAN distro there is a separate page) this meant that > in just 6 weeks of operation I had more than 160,000 rows in the > sessions table. Mostly useless entries. > > My possible solutions are: > 1) Recognize crawlers and not to give them cookies at all. Probably not the best solution > 2) Give out cookies only when someone has logged in. (or registered ?) This should be quite easy. Just make sure you do not call $self->session unless you really need to... If you always need to call $self->session to figure out if someone is logged in, then I would suggest you handle the cookies manually by setting SEND_COOKIE to 0 and calling $self->session_cookie manually when you know you have a valid session. You could do this in the same location as you do your authentication. > 3) Maintain some counter how many hits each cookie was used for > and run some cleanup process and remove cookies that were used > only once and are at least one day old. You will need some sort of cleanup process regardless. Usually this is done on a time basis (ie when was the last time this session was used). But basing it on a counter would be handy as well... Cheers, -- Cees Hek --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[email protected]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
