PHP sessions not displaying across pages [advanced issue]

[gmillikan]

I've been coding PHP for about 6 years now and this one's got me stumped, so it must be a simple syntax issue ;-)

Here's the issue: The SESSION is being set, read and updated just fine as long as I stay on a single page, "setcookie.php" but if I go to a second page "showcookie.php" which is in the same directory then the contents of the session are not displayed and instead a new session cookie is set.

Per notes below, it appears as though PHP is accessing the original session file (I'm looking its "atime") before setting (and writing to disk) the new session.

Very, very weird.

Any thoughts?

Thanks,

Geoff

PS. Take a look at the headers when GETting the second page "showcookie.php." You can see my browser is sending a valid session ID (the same one that was set on the first page) however it's receiving a new session ID in the response!

This is this first page [mydomain.com...]

session_start();
if (!isset($_SESSION['count'])) {
 $_SESSION['count']=0;
} else {
 $_SESSION['count']++;
}
echo '<a href="https://www.mydomain.com/dev/showcookie.php">Go to second page</a>';
echo '<pre>';
print_r($_SESSION);
print_r(session_get_cookie_params());

And this gives us:

_Go to second page_
Array
(
 [count] => 2
)
Array
(
 [lifetime] => 2592000
 [path] => /
 [domain] =>
 [secure] => 1
 [httponly] => 1
)

This is the second page at [mydomain.com...]

session_start();
print_r($_SESSION);
print_r($_SERVER);

The second page gives us:

Array
(
)


Array
(
 [UNIQUE_ID] => S7ET-NA5jJkAAA3fJOMAAAAB
 [HTTPS] => on
 [HTTP_HOST] => www.mydomain.com
 [HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5
 [HTTP_ACCEPT_ENCODING] => gzip,deflate
 [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7
 [HTTP_KEEP_ALIVE] => 115
 [HTTP_CONNECTION] => keep-alive
 [HTTP_REFERER] => https://www.mydomain.com/dev/setcookie.php
 [HTTP_COOKIE] => PHPSESSID=1fw1K3Xv6w6aKgTiBAt-IPFwt4a
 [PATH] => /bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin
 [SERVER_SIGNATURE] => 
 [SERVER_SOFTWARE] => Apache
 [SERVER_NAME] => www.mydomain.com
 [SERVER_ADDR] => 208.57.140.155
 [SERVER_PORT] => 443
 [REMOTE_ADDR] => 71.177.216.6
 [DOCUMENT_ROOT] => /home/healthpl/public_html
 [SERVER_ADMIN] => [e-mail]
 [SCRIPT_FILENAME] => /home/healthpl/public_html/dev/showcookie.php
 [REMOTE_PORT] => 14156
 [GATEWAY_INTERFACE] => CGI/1.1
 [SERVER_PROTOCOL] => HTTP/1.1
 [REQUEST_METHOD] => GET
 [QUERY_STRING] => 
 [REQUEST_URI] => /dev/showcookie.php
 [SCRIPT_NAME] => /dev/showcookie.php
 [PHP_SELF] => /dev/showcookie.php
 [REQUEST_TIME] => 1269896188
 [argv] => Array
  (
  )

 [argc] => 0
)

Here's the headers when accessing the second page:

https://www.mydomain.com/dev/showcookie.php

GET /dev/showcookie.php HTTP/1.1
Host: www.mydomain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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: 115
Connection: keep-alive
Referer: https://www.mydomain.com/dev/setcookie.php
Cookie: PHPSESSID=1fw1K3Xv6w6aKgTiBAt-IPFwt4a

HTTP/1.1 200 OK
Date: Mon, 29 Mar 2010 20:56:28 GMT
Server: Apache
Set-Cookie: PHPSESSID=gwLgrZ%2CSkQze0EgvFdETMpZbfQd; expires=Wed, 28-Apr-2010 20:56:28 GMT; path=/; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 1510
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html

Amazingly, it looks like PHP is accessing the original cookie before writing the new one because the "atime" on the original cookie file is updated. So this doesn't appear to be a permissions issue since the file is getting accessed - it's that the contents of the cookie are not getting displayed and a new cookie is being sent.

shell> stat /tmp/sess_1fw1K3Xv6w6aKgTiBAt-IPFwt4a
 File: `/tmp/sess_1fw1K3Xv6w6aKgTiBAt-IPFwt4a'
 Size: 10    Blocks: 2   IO Block: 4096 regular file
Device: 700h/1792d  Inode: 6107  Links: 1
Access: (0600/-rw-------) Uid: ( 99/ nobody) Gid: ( 99/ nobody)
Access: 2010-03-29 13:58:29.000000000 -0700
Modify: 2010-03-29 13:56:26.000000000 -0700
Change: 2010-03-29 13:56:26.000000000 -0700

[Readie]

I've never seen anything like this before... Has anyone fiddled with your browser security settings/preferences recently?

[CyBerAliEn]

Have you ever used sessions on this server setup before?

PHP is designed to create/start a new session (and cookie) if it cannot find/determine the previous session. It is possible it is a server/PHP configuration issue.

However, if you don't experience this problem on other pages/etc, it would indicate a more in depth issue it seem.

[Matthew1980]

Hi there gmillikan,

You have more than likely already done this, but would error_reporting(E_ALL); shed any light on this issue, I have had similar happen to me in the past where I had to declare the session_start(); in one of my include(); files so that I had image captcha & session globals access when welcoming a known user to the site. I conceded in the end, and now I can't set the session start any where other than in an obscure file.

As for this error, the only thing that you do that's slightly different to me is that you access the whole array, whereas I specifically access a given key, but this is just habit, and makes no difference when the code is parsed. I should like to know what causes this in the end :-)

One thing I notice is that you set it as http secure? I assume as this has some sort of cart data in seeing as you want to protect it, Or have I misunderstood the concept of the secure setting ;-p (probably) But normally when doing run of the mill type sessions, just having the path set to "/", whole domain, usually is the easiest method to adopt unless there is a specific folder hierarchy that you need to use, then you would declare it there (full URL helps..)

Whether it matters or not: $_SESSION['count'] = "0"; Again, my force of habit, when assigning var's I always use "" to encase the data, whether it's string or int. I may well be wrong, but I have never had an issue (now where is that wood that I need to touch...)

Just a few thought's there, but I agree, quite odd, I shall have a play with the code myself to try and replicate the "odd" behaviour.

Then again, are we all missing something simple ;-p

Cheers,
MRb

[gmillikan]

Readie: I tried 4 browsers, FF3, IE8, Chrome, Opera, all the same thing. No, no fiddling here, just crying.

CyBerAliEn: Good question. cPanel runs on this server. There is another domain which (I'm told) is handling cookies correctly however I haven't verified. Agreed, there's a config issue *somewhere* but where?

Matthew1980: Yes, to avoid man-in-the-middle attacks it's best practice to only send session id's over HTTPS requests. Dumping the whole session works just fine.

It's interesting that refreshing the second page, [mydomain.com...] the server issues a new SESSION id with *every* page load.

There's a load of php.ini files but only one is being loaded per below. cPanel is a horrible invention.

shell> locate php.ini
/php.ini
/etc/php.ini
/home/cpeasyapache/src/php-5.2.9/php.ini-dist
/home/cpeasyapache/src/php-5.2.9/php.ini-recommended
/scripts/php.ini
/usr/lib/php.ini
/usr/local/cpanel/3rdparty/etc/php.ini
/usr/local/cpanel/3rdparty/etc/php.ini,v
/usr/local/cpanel/3rdparty/etc/php.ini.dist
/usr/local/cpanel/3rdparty/etc/php.ini.keep
/usr/local/cpanel/3rdparty/etc/horde/php.ini
/usr/local/cpanel/3rdparty/etc/phpmyadmin/php.ini
/usr/local/cpanel/3rdparty/etc/phppgadmin/php.ini
/usr/local/cpanel/3rdparty/etc/roundcube/php.ini
/usr/local/cpanel/3rdparty/lib/php.ini,v
/usr/local/lib/php.ini
/usr/local/lib/php.ini,v
/usr/local/lib/php.ini-zend_optimizer.bak

But note that only /usr/local/lib/php.ini is being loaded per below:

shell> php -i
phpinfo()
PHP Version => 5.2.9

System => Linux pebblebeach.mydomain.com 2.6.18-164.2.1.el5.plusPAE #1 SMP Fri Oct 9 13:15:48 EDT 2009 i686
Build Date => Jun 15 2009 22:50:24
Configure Command => './configure' '--disable-pdo' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-libxml' '--enable-magic-quotes' '--enable-mbstring' '--enable-sockets' '--prefix=/usr/local' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-curl=/opt/curlssl/' '--with-gd' '--with-gettext' '--with-imap=/opt/php_with_imap_client/' '--with-imap-ssl=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-libxml-dir=/opt/xml2/' '--with-mcrypt=/opt/libmcrypt/' '--with-mssql=/usr/local/freetds' '--with-mysql=/usr' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-openssl=/usr' '--with-openssl-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--with-zlib' '--with-zlib-dir=/usr'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/lib
Loaded Configuration File => /usr/local/lib/php.ini
Scan this dir for additional .ini files => (none)
additional .ini files parsed => (none)
PHP API => 20041225
PHP Extension => 20060613
Zend Extension => 220060519
Debug Build => no
Thread Safety => disabled
Zend Memory Manager => enabled
IPv6 Support => enabled
Registered PHP Streams => php, file, data, http, ftp, compress.zlib, https, ftps
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters => string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, zlib.*
<snip>

[gmillikan]

Readie: Forgot to mention that other developers on other machines on other Internet connections appear to be getting the same thing. So it's not a client-side issue.

[gmillikan]

Here's what I get accessing the second page. Same thing every time - except the SESSION ID and times change.

Request Headers

GET /dev/showcookie.php HTTP/1.1
Host: www.mydomain.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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: 115
Connection: keep-alive
Referer: https://www.mydomain.com/dev/setcookie.php
Cookie: PHPSESSID=XNn8DTlAGSF81hnuGNrv4IFkWUa
Pragma: no-cache
Cache-Control: no-cache

Response Headers

HTTP/1.1 200 OK
Date: Mon, 29 Mar 2010 22:54:28 GMT
Server: Apache
Set-Cookie: PHPSESSID=CZ4EVpcb0CmoGN0GK47sCtZzs%2Cd; expires=Wed, 28-Apr-2010 22:54:28 GMT; path=/; secure; HttpOnly
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 1577
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html

[eelixduppy]

Odd. It seems you might have to contact your host on this one....

What are your php.ini session directives set to?

Also, if you are OK with a rather lousy temporary solution passing the session ID through the URI should do the trick.


Oh, and also make sure you aren't auto-prepending a file to these scripts. I cannot tell you how many times that has messed me up.


One more thing....you wouldn't happen to be moving across subdomains, would you? Or perhaps in and out of https?

[gmillikan]

eelixduppy: You're kidding right, SESSION ID in the URI? Horrible. This isn't 1991. :-) Nope, no auto-prepending. The file above is exactly as it is on the server. Both files accessed via HTTPS, exactly the same domain, and the two files are in the same directory. No 301 redirects. Nothing fancy. Just two pages. Here's the php.ini part that deals with SESSIONS:

session.save_handler = files
session.save_path = "/tmp"
session.use_cookies = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 2592000
session.cookie_path = "/"
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 1000
session.gc_maxlifetime = 2592000
session.bug_compat_42 = 0
session.bug_compat_warn = 1
session.referer_check = "www.my-freaking-old-domain.com"
session.entropy_length = 512
session.entropy_file = "/dev/urandom"
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 1
session.hash_bits_per_character = 6

[gmillikan]

Well, there it is. Dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it, dang it.

session.referer_check. It's set to some old domain name we're no longer using.

See, simple syntax issue.

Dang it.

[Matthew1980]

Well gmillikan :)

Just proves that even experienced people make schoolboy errors! (not on my own there at least ;-p)

At least you found it in the end. Made me want to re-check my issue anyway ;-p

Have fun with the rest of the project.

Cheers,
MRb

[gmillikan]

Matthew1980: Chiding accepted. ;-) Thanks for the assistance, hopefully I can return the favor.

For anyone reading this post for the next few years laughing at this thread you can bypass all the reading you did and just hit [php.net...]

[edited by: eelixduppy at 1:20 pm (utc) on Mar 30, 2010]
[edit reason] changed link [/edit]

[eelixduppy]

Yea I was reluctant to mention the session ID in the URL like that, however, if it works it works, right. ;)

Glad you figured it out. It wasn't that painful after all.

[gmillikan]

eelixduppy: Going with what works is a good thing! I just wanted to give you a hard time. It's funny that your simple question of asking to look at *all* the sessions settings is what solved it - the session.referer_check parameter is much lower in the php.ini file than the normal session settings (down by the gc garbage collection) so I kept missing it.

Painful? Pain is weakness leaving the body. ;-)

Thanks everyone.

[CyBerAliEn]

It's good to see you found your solution! I knew it had to be a configuration issue. :)

Best of luck with the rest of your project!