Page 2 of 2

Posted: Thu Feb 16, 2006 12:38 pm
by chrys
redmonkey wrote:I use an isset method mainly as it will run and won't issue any notice level warnings if the var doesn't exist, however, that's a completly different box of frogs than what we are dealing with.

There are some third party applications around for inspecting packets and headers being set. Which operating system are your users (or you able to debug on) running?

The most well known is ethereal but that is probably overkill for your needs.

Presumably there's a Firefox extension that allows you see headers being sent as well as recieved?
Yeah, everyone uses FireFox here on Windows XP Pro.

I'm going to investigate the server-side sesion files first.

I just find it bizarre that people are getting auto-logged out even tho I set the cookie time ot be 10 hours.

Posted: Thu Feb 16, 2006 12:52 pm
by redmonkey
Your php.ini file wrote: ; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
I make that 24 minutes, it's possible your sessions are probably being cleaned by the garbage collection while your user is out to lunch.

Posted: Thu Feb 16, 2006 1:04 pm
by chrys
redmonkey wrote:
Your php.ini file wrote: ; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
I make that 24 minutes, it's possible your sessions are probably being cleaned by the garbage collection while your user is out to lunch.
I set mine to the same as the cookie lifetime.. 10 hours lol

Posted: Thu Feb 16, 2006 1:52 pm
by redmonkey
Ah right, that was from one of your previous posts, I must of missed that.

It may be that the /tmp is becoming over populated with files? /tmp is the default temp directory for most apps so that's where all running apps will write their temp data. If you have a large user base you could get quite a few files in there for sessions alone within a relatively short space of time. The actual max file count per directory is OS dependant, it is quite large, so may or may not be an issue.

Most stuff has been covered already but i'd be looking at the following....

Session data files are being created.
Session data files are being updated
Session data files do contain expected data
Client is sending the correct cookie values within the header request
Server is sending the correct cookie values within the header responses

As susgesseted by someone else, check that session_id() is returning the same value as the session ID within the users cookie file.

If all of that adds up then it would appear to be a communication breakdown between PHP parser and script. Only real way to nail that is write your own session handler which will give you are finer grained debugging ability with what is going on under the hood.

TBH, whenever I need session support (not very often) I've always used a custom session handler, I find it that little bit easier to manipulate.

Posted: Thu Feb 16, 2006 2:08 pm
by chrys
Thank you all, thank you redmonkey.

I will let you know how it goes. I am not ready yet to create my own session handler until I have exhausted my chances of unearthing this bug.

Cheers!

Posted: Thu Feb 16, 2006 2:09 pm
by RobertGonzalez
HTTP Live Header Firefox Entension.

Sorry about not looking at the function. Something to take note of, checking against $_SESSION['var'] may have unexpected results in that the session array var value might NOT evaluate to TRUE or FALSE. There is a possibility that is evaluates to empty. That is why I throw comparisons into the mix that I expect the script to find.

Knowing that there are two things to look for (a set session var and a value for that session var) leaves out any chance that you will get something different. Either it will or will not be set, and, if it is set, it either will or will not match what you are comparing it to. Makes checking session condition a little easier.

Something else you can do is set a cookie with a value of PHPSESSID so that you can check whether the current session id matches what was set in the cookie. If it does, then your session should still be alive. If it doesn't, for sure your session is dead.

Posted: Thu Feb 16, 2006 2:24 pm
by chrys
Everah wrote:HTTP Live Header Firefox Entension.

Sorry about not looking at the function. Something to take note of, checking against $_SESSION['var'] may have unexpected results in that the session array var value might NOT evaluate to TRUE or FALSE. There is a possibility that is evaluates to empty. That is why I throw comparisons into the mix that I expect the script to find.

Knowing that there are two things to look for (a set session var and a value for that session var) leaves out any chance that you will get something different. Either it will or will not be set, and, if it is set, it either will or will not match what you are comparing it to. Makes checking session condition a little easier.

Something else you can do is set a cookie with a value of PHPSESSID so that you can check whether the current session id matches what was set in the cookie. If it does, then your session should still be alive. If it doesn't, for sure your session is dead.
PHP naturally sets a cookie called PHPSESSID on the user's computer. I will add a new session var logged_in and set it to true and just check for that from now on.

Posted: Thu Feb 16, 2006 3:46 pm
by RobertGonzalez
I have had problems with the PHP cookie PHPSESSID. It seems (at least in the few apps that I have had problems with) that when the session ID is reset after garbage collection time is up, that the cookie value of the session ID is changed to mirror the new reset session id. That is why I set a cookie of my own to use as a checker.