Forum Moderators: coopster
How do I clean out all the "old" sessions so that my session table doesn't explode?
delete from session where date_created < date_sub(now(), interval 2 day)
or some such.
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.
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>
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...
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?
eegads, what would that do?
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.
