session problem with login script

[Tom]

I hope someone can help me figure out what's going on here. I've
re-read the section on sessions at php.net and Googled this high and
low but I haven't found anything that quite explains my problem.

The basic problem: session data (e.g. $_SESSION['access_level']) gets
dropped after visitor logs in and reloads the page via a form once or
twice (it seems to vary), requiring the visitor to re-login, whereupon
the problem repeats itself.

An outline of my login script:

1. a function protect_page at the beginning of the protected page's
script checks to see if the visitor is logged in by checking two
session values ($_SESSION['access_level'] and $_SESSION['login_time']).

2. if logged in with sufficient access and session not too old, show
page. if not, require_once an include file that displays a login form
(everything's buffered, so it's not a header problem)

3. post login form, check credentials; if ok, display protected page

I have a log that tracks the behavior but it's a bit too long to
include here. One peculiarity I've noted is that after logging in,
when I post the form on the protected page, it appears to successfully
load the page once with the session data. But then it reloads the page
a second time (according to the log) and the session data is lost --
thus logging me out! There's nothing in the script that should trigger
the page to be reloaded. I use session_regenerate_id to avoid session
fixation. Could this be a factor?

Another complication: this problem occurs on two development servers
(one running XAMPP on Linux, the other WAMP). But on a third running
WAMP, it doesn't happen and everything runs as designed.

Finally, I took note of the following posts describing similar problems
with session data being lost:

Initialize crucial SESSION data
(http://us2.php.net/manual/en/functio...lose.php#63970)

Use session_write_close after assigning crucial SESSION data
(http://us2.php.net/manual/en/ref.session.php#62486)

Turn off ZoneAlarm (http://forum.sydphp.org/index.php?a=topic&t=255#p7)

However, the suggestions offered (e.g. using session_write_close()
liberally, turning off ZA ) did not solve my problem. And my php.ini
file appears to be in order.

I hope this is clear and detailed enough. Does anyone recognize it?
Any help is appreciated.

Tom

[fletch]

> The basic problem: session data (e.g. $_SESSION['access_level']) gets

dropped after visitor logs in and reloads the page via a form once or
twice (it seems to vary), requiring the visitor to re-login, whereupon
the problem repeats itself.
The reason this happens is to do with the sessionid being lost. It is
either passed by cookie or by url. The first thing to check is that
session_start() is called before any output to the screen. Place a
die('.'); before the session_start() calls of you script and view
source. White space is considered output and is not allowed.

Assuming that didn't sort things out then the next step is to check
that the sessionid is being passed. First check your cookies, and see
if there's one there. Then turn off cookies to force the sessionid to
be passed by url. There are some circumstances (although I can't of the
top of my head remember what they are) where PHP fails to add the
?PHPSESSID=xxx to a url. If there is nothing really odd about your
script (like running everything through exec()) then this step is
probably a waste of time as it will work.
I use session_regenerate_id to avoid session fixation. Could this be a factor?

Yes. I don't see the need for it for one, and according to the comments
in the manual other people are losing session info because of it.

[Tom]

Thank you for the response, fletch. It appears session_regenerate_id
was the culprit. (I thought it was one of the factors I had controlled
for, but apparently never got around to it.) I suppose this might
account for the unexplained script reloading (unless I'm misconstruing
normal HTTP interaction.)

I had read some warnings on session fixation that I thought recommended
using session_regenerate_id systematically as a precaution, but I may
have misunderstood the implementation. I'll have to revisit.

In any event, thanks once more. An immense relief.

Tom