Sessions - temp. files

[Anon]

Hi guys,

I have a quick question. I am using PHP4.2 on Windows 2000 + Apache 1.3.

I have the following set up:

• register_globals = ON (sorry. but i still have to migrate to $_SESSION)
• cache_limiter=nocahe (default)
• cache_expire=180 (default)

(I am not sending any cookies to the clients' machines)

I would expect the temporary files being deleted after 180 minutes (cache_expire) but this doesn't actually happens. Am I missing something?

Thanks for your answers,

Vin

[Anon]

PHP's documentation is awfully vague on this I find.

(You're not sending cookies? So the URLS on the browser all have ?PHPSESSID=... in them? Oh, you mean other cookies.)

You also need to look at the garbage-collection settings, which determine when dead sessions are actually deleted.

[Anon]

Well, ?PHPSESSID=blabla isn't actually displayed in any of the pages where session's variable are requested (it is a guess because I mostly use frames layout and they appear not to be visible in any condition. In fact abou the session ID I tend to assigne a custom ID number to keep some track of it.

I changed the garbage collection setting from 1440 secs in:
session.gc_maxlifetime=1

But session's files are still there. And full of data!
This sounds so wierd to me. I was kind of trying to rely on this expiration time. In fact my goal is to prevent double log-ins from users using different computers at the same time. I wanted to do this by checking whether or not the sessioin temp file exists (I name them using a trackable id which depands by the users' log in, these file hence have real simple names like sess_23 sess_40 etc.). Now, it's obvious that if you properly log-out the session will be destroyed (session_destroy) but if you just close your browser, the session will remain there forever (or until whenever PHP decides to clean all unused sessions) thus the system will never let you in thinking you're trying to double log-in with the same user's account.

Vin

[Anon]

Did you crank up the session.gc_probability to 100 (it's a percentage) as well?

But of course, if you do that, no session lasts for longer than gc_maxlifetime seconds...

Well, that's not quite true. Garbage cleanup happens whenever a new session starts - so one session will last forever until another session comes along.

[Anon]

In the end you have a "who's currently online" problem, with the only difference being why you want to know.

[Anon]

indeed, the method is supposed to tellme who's currently on-line and avoid that the same "who" will log-in twice or more time from different locations. I did play a bit with percentage (set to 100). This time the session lasts until a new user logs in, as you were predicting but, whatever maxlifetime you have set, the previous session is distroyed and the previous user redirected to the log-in. Wierd, it does look like I am missing something huge here, or there is a bug or misscomcept on how sessions are handled by PHP 4.2 (with 4.1 was the same though).

vin

[Anon]

If you're pairing session IDs off with users already, then if someone attempt to log in a second time on another machine, without logging off of the first, you basially have two options:

1) deny the new login and retain the old login
2) kill the old login and permit the new login

Using any sort of "who's online" method could cause inconsistent behaviour in the first case. If the old session is still being treated as "active" then the attempted new login will fail, but once the session expires they'll suddenly be able to log in.

The problem comes in because PHP only actually runs when it has a script to process; it hibernates in between scripts. So anything you want PHP to do has to be triggered by a script being requested. Even deletion of old sessions is like this (which is why a session with a max lifetime of 1 and collection probability of 100% actually lasts until the next time a script is hit.

What you really want is something that does monitor your session data on a regular basis. Something that will wake up on a regular basis, look around, and sees if it has anything to do. In short, a cron job. One that wakes up every minute (that's the shortest interval) and delete "stale" session files - those with a modification time older than n minutes ago.

You've got a tradeoff, of course: make it too short and you'll have users getting kicked out because they stopped to pick up their pen. Make it too long and you're back to having sessions sitting around that you don't want.

If you kept the randomish element of the session ID around, you could tell if they were attempting to use a different browser from the one they're currently logged in to. Actually, that gives you a third choice:

3) Ask the user which of (1) and (2) they want.