Welcome to WebmasterWorld Guest from

Forum Moderators: coopster & jatar k

Message Too Old, No Replies

php: how to delete sessions on browser close?

My session table is getting huge!

4:38 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

I have a dynamic site that uses sessions to "follow" users. But most users don't obediently click on the "logout" link that deletes their session. So when they move on, or close their browser, their session record remains in the corresponding database table.

How do I clean out all the "old" sessions so that my session table doesn't explode?

4:41 pm on Oct 2, 2002 (gmt 0)

10+ Year Member

I put a date on mine and run a cron job every once in a while (daily?) to delete sessions more than a day or 2 old.

delete from session where date_created < date_sub(now(), interval 2 day)

or some such.

4:53 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

uh-oh. I'm just learning php/mysql. What's a "cron job"?
5:44 pm on Oct 2, 2002 (gmt 0)

10+ Year Member

on unix machines, there is a way to run regularly scheduled jobs. You use the "crontab" command to set up things to run at regularly scheduled times. It's generally used for things like backing up stuff, rolling over log files, and stuff like that.

I think there's a simiar thing on windows machines, but I can't remember much about it.

Anyway, you use crontab to edit a file with a bunch of seemingly cryptic stuff in it that will execute your script at the right times. google around for an introduction to crontab. Ask your hosting provider if you can set up cron jobs. You usually can if you have SSH or telnet (interactive) access to your machine.

6:16 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

Another approach, not quite as elegant but available even if your admin has disabled cron (or whatever its windows equivalent might be) for users, is to include it in some code that gets executed on your page fairly often. (I'm still not clear on the reasons for doing this, but enough people do it that knowing a work-around or three is good.)

One of my sites does this in the login code, eg:

"Delete from Sessions where (current_timestamp - lastused > $session_timeout);"

It doesn't mean that the session table will always be at its smallest possible size, since sometimes nobody logs in for hours, but it gets rid of stale logins often enough that the session table doesn't get huge. After all, every time you generate a new session, you also get rid of any stale ones.

NB: if you do something like this, with or without cron, you probably want to make sure that *every* page load updates the 'lastused' column

<added>btw, 'current_timestamp' above is a PostgreSQL function. I'm sure MySQL has something similar, but I don't know what it is. 'lastused' is meant as a column name, and $session_tmeout as an interpolated variable. </added>

7:02 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

Many thanks to both of you for the answers! Since I don't know whether my hosting provider permits cron jobs, and since I'm not a very experienced server person, I think I'll go with dingman's solution - but thanks for the "introduction to crontab" - I have heard that term several times and never known what it means.
7:10 pm on Oct 2, 2002 (gmt 0)

10+ Year Member

I got another idea for you: When someone logs in, delete all of their old, stale sessions. This will make sure that you never have more sessions than users. Worth a mention, at least.
7:31 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

Amoore: I thought about that one, but then I figured that either way you add the overhead of an extra database query, so you might as well get all the stale sessions rather than just one user's. I could be wrong, but I think it matters much more how many queries you make than what they are for page load time in the vast majority of cases. In my own case, I also wanted to avoid using a solution that would neccesarily rule out multiple simultaneous logins by the same user, though of course in some applications that would be a feature rather than a bug.

Not that yours wouldn't work. It would limit the size of the session table to not more than the number of users, wheras mine limits it to the number of sessions that have been used within the last n minutes - probably smaller in most cases, I think, but theoretically unlimmited.

Hmm... it occurrs to me that my method could fall victim to an attack by a user of the form:

perl -e 'while(`wget [mysite.com...]

Maybe I should close that hole...

9:05 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

< perl -e 'while(`wget [mysite.com...] .... >

eegads, what would that do? I'm beginning to wonder whether my own "beginner php site" may be insecure - is there a lot to worry about on that front?

9:51 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

eegads, what would that do?

It would log in, over and over and over... (Assuming you allowed login parameters to be passed by the GET method, but the script would only need slight modification to use POST instead, so don't think that makes you safe.)

If it was only run from one host, it probably wouldn't be too much of a threat badwidth-wise, though it certainly wouldn't be nice. (I wouldn't worry about that. If someone has enough bandwidth to DOS you that way, it doesn't matter how your script is set up or even whether there are any) However, it would tend to make your session table huge if there wasn't some check on number of sessions beyond what I described earlier. If that went unchecked, and they could make enough requests before your timeout kicked in and started deleting rows from the table of sessions, it might be possible to fill whatever disk partition your database server is keeping the table on. Depending on how things are set up on that server, that could range from making logins impossible to crashing the whole server.

On the bright side, this would 'just' be a DOS vulnerability, I think, which means it wouldn't open you up to exposing sensitive data. Still, it's the sort of thing I'd want to avoid.

As for the general issue of how secure a beginner PHP site is - it depends on a lot of things. If you don't accept input from the user, it's pretty safe. If you accept input from the user, but only display it on the output pages, it's still unlikely that the user can compromise your server, but a user who knew enough might be able to write malicious code to do something like load and run a malicious Java applet. (By including it in a post like this, for example.) Their script might then be executed by another user who trusted your site not to have malicious content. Finally, if you execute programs outside of your script with user input, you need to be extremely careful about what that input looks like before you pass it on.

Read the chapter on security in the PHP docs, and you are at least off to a good start. The most important thing to remember is that you should never trust user input.

10:04 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

Many thanks again, dingman, for a great answer - I am educated, and know now where to look for more. :)
10:10 pm on Oct 2, 2002 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

You're quite welcome. I should give warning that I know enough about security to be a danger to myself and others. If anyone sees something wrong or incomplete in what I say on the matter, I'd be interested in being further educated. And anything I say is safe should probably be double-checked :)

Featured Threads

Hot Threads This Week

Hot Threads This Month