PHP sessions stopped working

(I logged a support request (with username/password), but figured I'd check here too)

Both my production and dev sites use PHP session management to keep track of usernmae/id/etc. Sometime within the last two weeks, session management broke (fortunately, my prod site is currently relatively inactive - it's in a public beta, while I await a edveloper performing an interface redesign). Nevertheless, the problem is occurring on both sites.

In analyzing the problem on my dev site, using the following code snippet:

<pre><?php print_r($_SESSION); ?></pre>

I can see the session vars on the login page, upon logging in:

Array
(
[username] => gleep
[last_visit] => 2006-02-01 15:51:49
[user_type] => 600
[user_id] => 2
)

but as soon as I go to any other page, all session vars disappear:

Array
(
)

This particular empty array display comes from the "Home" (index.php), which is the only page that I've applied the snippet to besides the login page. However, it doesn't matter what page you go to after logging in, the problem recurs. (You can tell because the side bar menu reverts from "You are logged in as" to "Login")

You can log into the dev site -
http://coolgeek.dreamhosters.com/index.php and see the problem for yourself.

A note on site architecture: all pages call templates/header.inc and templates/footer.inc. The first lines of header.inc are:

<?php
session_name ('HAVisitID');
session_start(); // Start the session.
?>

The last code change on the site occurred on 1/16. The last time that I can be CERTAIN that I logged in and successfully performed work through the site is 1/17. As such, I can be reasonably certain that the problem does not lie with a code change on my part.

Were there any PHP upgrades/patches, Linux patches to Yoda, etc?

What else could be causing this problem?

This is the session cookie set by your program:

Name HAVisitID
Value b4241930b02772ee333eb30662e5f840
Host coolgeek.dreamhosters.com
Path /
Secure No
Expires At End Of Session

You should use firefox / the web developer toolbar and LiveHTTP headers to see what your site is sending back and forth. IT may help you diagnose your problem.

You didn't move to PHP5 did you?

Chekc this post out:

http://php.mirrors.ilisys.com.au/manual/en/function.session-start.php#59323

Thanks for the quick response herods.

phpinfo reports 4.4.1 I don't know if this matters or not, but it lists the session ID as PHPSESSID. I've been using HAVisitID as the session name for many months, but could that be causing a problem?

I shouldn't have an issues such as is noted at the php doc page you linked, because as I originally noted:

(quote)

A note on site architecture: all pages call templates/header.inc and templates/footer.inc. The first lines of header.inc are:

<?php
session_name ('HAVisitID');
session_start(); // Start the session.
?>

(unquote)

The call to header.inc is at the top of every page except login.php. This is so that login.php would display a menu bar properly depending on whether the user was logged in or not. Again, though, this hasn't changed in months.

Finally, I am using Firefox/Web Developers Toolbar. View cookies shows the same thing that you're seeing (albeit with a different value).

I just installed LiveHTTP Headers and got the following. Nothing looks out of place to me, but I'm not particularly knowledgeable on HTTP headers.

The path I followed was

http://coolgeek.dreamhosters.com/
http://coolgeek.dreamhosters.com/login.php (pre-submission)
http://coolgeek.dreamhosters.com/login.php (post-submission)
http://coolgeek.dreamhosters.com/index.php

(start LiveHTTP Headers display)

http://coolgeek.dreamhosters.com/

GET / HTTP/1.1
Host: coolgeek.dreamhosters.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
Date: Thu, 02 Feb 2006 01:42:17 GMT
Server: Apache/1.3.33 (Unix) DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.1 mod_ssl/2.8.22 OpenSSL/0.9.7e
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
X-Powered-By: PHP/4.4.1
Set-Cookie: HAVisitID=40247f8ce136ddb12629dfef6e6bf496; path=/
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 2051

How are you copying the values out of the request (username etc) into the session?

there should be somethign in your code where you go:

$_SESSION['username'] = $_REQUEST['username']

Because thats the only reason I can see, the setting of session cookies is occuring, and the browser is sending it back to the server, so the issue has to be where you are assigning the request contents into the session.

Set vars from MySQL I/O:

$username = $_POST['username'];
$last_visit = $row[2];
$user_type = $row[1];
$user_id = $row[0];
$ut = $row[3];

Set session vars:

session_name ('HAVisitID');
ini_set ('session.use_cookies', 0);
session_start();
$_SESSION['username'] = $username;
$_SESSION['last_visit'] = $last_visit;
$_SESSION['user_type'] = $user_type;
$_SESSION['user_id'] = $user_id;

Again, unchanged for months

Just saw this on PHP Manual

http://us3.php.net/manual/en/ref.session.php#51351

"hi all,
i've been troubles with sessions at my production server for weeks and today i've noticed the problem.

If you use /tmp as php sessions file dir, on a procuction server, system garbage will delete randomly files when a certain number os files are stored at tmp, so some sessions are deleted within 1 seconds, like my case.

Solution? use another dir for php sessions file, and be careful of using a shell script for your own garbage collection, called from cron, with this line:
cd /path/to/sessions; find -cmin +24 | xargs rm

Spud."

Just for ha-has, how would I go about setting a different directory, and would a subdirectory of my DH home dir be a safe place for that?

Um, according to the documentation

ini_set('session.use_cookies','0') turns OFF using cookies for sessions.

I think you just want to leave it as the default, or use

ini_set('session.use_cookies','1')

See:

http://au3.php.net/manual/en/ref.session.php#ini.session.use-cookies

If it used to work, and now doesn't then I'd say *could* be a PHP upgrade which 'fixed' the fact the problem you were exploiting.

I thought that I had read that one shouldn't use cookies for sessions because of either or both of:

- security reasons
- browsers that refused cookies

If both of these are invalid, I'll make the change

Actually, using cookies for sessions improves security.

The problem with embedding session id's into urls is that you have the session id turn up in all sorts of places, most notably the referrer url when people click off site.

For instance, there is a popular job hunting board in australia, they allow you to embed an html resume. In my html resume I embedded a meta - refresh to my php based resume off site.

This resume traps the referrring url. Because the job board embeds their session id's into their urls, I get they agency's session turn up in my logs. If I'm quick, I could use that url to log onto the board as the agency and hijack the session. (Of course, thats a purely theoretical attack, I've never done it :)

Finally, I feel users who refuse cookies deserve to be excluded, there is no viable privacy/security risk of accepting a non-persistant session cookie for the purposes of using a website. The entire Ruby On Rails frame work actually mandates it!

Yeah, I read Shiflett's Essential PHP Security and am somewhat familiar with session highjacking, though I believed that it was an exceptionally rare situation, rare enough that if it really mattered, you should be using ssl or https.

setting session.use_cookies to 1 DID fix the problem, and I'm not married to the idea of being inclusive to users that refuse cookies.

Are you convinced that this was in fact the problem, that I was unknowingly exploiting a bug in PHP?

I ask because my understanding is that use_cookies=0 SHOULD work. I wonder then if it is the GC issue specified in that PHP session handling page.

In any case, I want to thank you profusely for your help. If nothing else, I've got a fallback that resolves the issue. DH hasn't responded to my support request yet, but I made it a cgi/site issue, rather than a site outage, since I'm still in beta. So that makes your help all the more important.

Hope I can return the favor some day.