|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #43682 domain/subdomain problems with session cookies
Submitted: 2007-12-26 21:00 UTC Modified: 2008-04-13 22:50 UTC
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: k dot andris at gmail dot com Assigned:
Status: Closed Package: Session related
PHP Version: 5.2.4 OS: Debian Sarge
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: k dot andris at gmail dot com
New email:
PHP Version: OS:


 [2007-12-26 21:00 UTC] k dot andris at gmail dot com
The $_SESSION variable is empty when I look at it on a subdomain ( even though session_id() is the same as on the main site ( Sessions are saved in files under /var/log/php5 - they just not read from there. The session cookie is OK too.

Reproduce code:
I have this on the base domain and on subdoamins too with different assigment lines. Still, they only seee their own assigments.

ini_set("session.cookie_domain", "");

$_SESSION['main'] = 'main'; // assigment


Expected result:
Since I have the same session id, I expect the $_SESSION variable to be shared acreoss pages, and subdomains.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-12-27 00:27 UTC] k dot andris at gmail dot com
Works all right in 5.2
 [2008-01-18 01:31 UTC]
I'd check first that the cookie is actually set and with what data.
I had some problems with this when I changed the domain to be something different what it originally was, and as there already existed a cookie with same name, but just set with domain '' it wasn't reset. (tested using Firefox)

Try change the session name (ie. cookie name) too.

 [2008-01-18 13:15 UTC] k dot andris at gmail dot com
Thanks, I'll try it. 5.2.4 works OK, too. My 5.2.5 was from dotdeb and not the official sources.
 [2008-01-26 01:04 UTC]
If you're not using the sources we provide, then we can't help you. But if you can reproduce this using fresh sources from then we can talk more.. I have NO problems with sessions in subdomains.
 [2008-02-01 19:47 UTC] k dot andris at gmail dot com
Now I'm closer to see what's causing this... It only happens with a vhost serving a wildcard subdomain. When all * requests go to a single /var/www/index.php file. When I serve subdomains from /var/www/subdomain/ it works ok. I'm using lighttpd with fastcgi. I'l try to see if the problem is with lighttpd or php, but if you can test it with Apache... Thanks.
 [2008-02-01 22:35 UTC]
Sounds like a lighttpd problem to me. I only use lighttpd but I don't have any wildcard dns names set. Perhaps lighttpd doesn't set the host properly that is passed to PHP (or actually any other fastcgi..)

 [2008-02-01 22:36 UTC]
Try check what the domain actually is in that /var/www/index.php file.

 [2008-02-02 13:11 UTC] k dot andris at gmail dot com
So on subdomains it does work all right. What clears the $_SESSION variable is the root domain. Session is passed fine between and, but if I open a session at, it will not see the subdomain's session variables, and it will also erase them. The session cookie passes along fine. I call: 

ini_set('session.cookie_domain', '');

I thought it does not work because the dot befor thee site's name (since the root does not have that dot), but removing it does not help either. Can you test this?
 [2008-02-02 13:15 UTC] k dot andris at gmail dot com
Host names pass along fine to the script handling the subdomains. Actually I used the subdfomain name to set test session variables, like "a_test2 and "b_test".
 [2008-02-05 00:28 UTC]
Try using this instead of ini_set():

Calling this with proper values prior to calling session_start(); works just fine for me.
 [2008-02-10 17:21 UTC] k dot andris at gmail dot com
Did you try getting the session variable set on a subdomain at the root? Like sets $_SESSION['apple'] = 'fruit', but will not see it. Or does it in your tests? BTW, session_set_cookie_params lack parameter docs, but I guess lifetime is in seconds.
 [2008-02-10 18:17 UTC] k dot andris at gmail dot com
It seems to work on another server. I'll try to find out what was wrong with the first one.  Sorry..
 [2008-02-10 18:29 UTC] k dot andris at gmail dot com
I found it! The problem only occours if you serve the base domain and the subdomains from different sections of lighttpd config file, like this:

$HTTP["host"] =~ "^mysite\.com" {
  server.document-root = "/var/www/mysite/"

$HTTP["host"] =~ "(.+)\.mysite\.com$" {
  server.document-root = "/var/www/mysubdomains/"
 [2008-02-13 18:39 UTC]
I don't see how this is PHP bug at all. More like lighttpd bug if a bug at all. Check these: What host PHP script gets from ligttpd ($_SERVER['SERVER_NAME'] and what is tried to be set for the cookie. 
 [2008-02-21 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2008-04-13 22:50 UTC] k dot andris at gmail dot com
Actually Suhosin's suhosin.session.cryptdocroot option was the problem. If the session encryption key is based on the DocRoot it causes the problem described here (if the base domain and the subdomains are served from different directories).
 [2010-03-26 15:00 UTC] serhio_forever at yahoo dot com
To "k dot andris at gmail dot com"
You're right. Had exactly the same problem.

Solution. Just add these 2 lines in your php.ini file:


or, if you don't have access to it, these 2 in some of your general config.php file:

ini_set("suhosin.session.cryptdocroot", "Off");
ini_set("suhosin.cookie.cryptdocroot", "Off");
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 21 23:01:29 2024 UTC