I'm having a really strange problem with some of my PHP code. I have error reporting turned on and nothing's coming up either.
Basically I have a form that pushed data to $_SESSION[]. The code is:
<?php
session_start();
$_SESSION['contact']['name'] = $_GET['name'];
$_SESSION['contact']['email'] = $_GET['email'];
$_SESSION['contact']['question'] = $_GET['question'];
session_write_close();
header('Location: confirm.php');
exit;
?>
This is working. However, completely at random the confirm.php will or will not recieve this data. If I refresh multiple times I sometimes get the data, sometimes not.
Here's the confirm code:
<?php
ini_set('display_errors', 'on');
error_reporting(-1);
session_start();
print "SeshID:" . session_id() . "<br>";
print "CookieID:" . $_COOKIE['PHPSESSID'] . "<br>";
print "Status" . session_status() . "<br>";
print "Loc" . session_save_path() . "<br>";
print "Cookie";
print_r(session_get_cookie_params());
print "<br>Data:<br>";
print_r($_SESSION);
?>
Again, no errors. Nothing appearing that looks obviously wrong.
The strange thing is that sometimes when I refresh the confirm page I will get an empty "Array ( )". Sometimes I'll get "Array ( [contact] => Array ( [question] => test [name] => [email] => test#test.com) )" for seemingly no reason...
I'm running no other scripts in between doing this - only the script above that checks the content of the session (confirm) need be re-ran and only the data somehow changes. I run the form a few times, then this check script and it's entirely inconsistent. The session and cookie IDs never change and are always the same
Is there some PHP setting I'm missing? It's really weird to me that these are seemingly pulling out old data which has been overwritten.
Solved!
I'll post my own answer for people with the same problem. Thanks to the people who helped in the comments for discovering this for me!
The Problem
The problem was that the server was using a cluster or distribution network, mine Azure, to serve the PHP files.
The first call writes the session data to machine 1, and the confirm is then reading from machine 2, which doesn't have the right info. In clusters, /tmp is often not mirrored, and that is where the session data is stored. Talk to your cluster admin about this. – Bart Friederichs
It seems like the form was being sent and having the session variables stored on server 1, but the page pulling the session data was server 2, server 3 and sometimes server 1 - hence the odd behaviour of seeing prior submissions and occasionally correct data.
The Fix
There are two possible fixes here. One:
The session store directory isn't being mirrored across all servers
In this case, change your session directory by changing "session.save_path" in your php.ini or by using
session_save_path(dirname(__FILE__). '/sessions/');
at the top of the affected files before you call session_start() (this was the ONLY part of our site that uses sessions so this made for a good / dirty fix).
The point here is to change it to a directory that is for sure being mirrored across every server in your cluster.
The session is being saved in another way that isn't mirrored
In my actual case I found that my session handler was the problem. By using
phpinfo();
I found that my session.save_handler was "wincache", which is a plugin to speed up PHP. One of the ways it appears to do this is by using shared memory or something in order to speed up the loading of the session data.
Either way, this was not right for my setup and I fixed it by simply changing the variable to use the default: 'files'.
Again, the best way to do this is by using your php.ini and setting session.save_handler to "files" but I don't have access to that file and so, again, I just used a call in the header of the two files before session_start().
ini_set("session.save_handler", "files");
I wouldn't recommend this as you know it's going to come up and bite you in the backside later on when a new developer comes in and you forget - it's better to change your .ini
Anyway, that was that.
Thanks everyone for your help!
Aside
Many server solutions such as Azure actually offer their own plugins and session handlers specifically to counteract this kind of situation. If possible you should of course use them!
After refreshing the page the session is still authenticated, but we lose the things we've added manually using the instruction
try this one
(this.set('session.X', 'Y'));
I have a simple file to set a session variable
<?php
session_start();
$_SESSION['my_name'] = "dave";
?>
and a simple file to see the stored variable
<?php
session_start();
echo $_SESSION['my_name'];
?>
if I call the file in the browser the session value is displayed correctly but if I make a ajax call using for example using http://requestmaker.com/ or https://www.hurl.it/ then the body response is blank. I can't see what is going wrong here its driving me nuts.
Any ideas
Cheers
Dave
You're trying to watch $_SESSION['user_name'] variable when you saved the $_SESSION['my_name']. variable
Correct one of the identifiers.
Its inappropriate to use third party http-request sites and still expect the session variables to be valid since the request is then coming from a different domain to your server.
As the title suggests, I am having problems trying to move an existing site over to a new host.
I have edited my .htaccess find to point the php.ini session.save_path value to a new folder stored in my non public root.
This is working fine, I can see the sessions appear in this folder, with the correct entries written to them.
But for some reason, my scripts cannot make use of these sessions, as in the variables associated to them hold no value, as in, they come out blank.
Now, these scripts are in use on my old host and do work perfectly. And comparing the actual session data, once the files have been downloaded off each host, they are both exactly the same.
This leads me to think that this could be a server side issue. Possibly another php.ini value.
Has this happened to anyone before, or can anyone suggest a reason behind this kind of behavior.
It anyone has absolutely any input regrading this, or could point me in the right direction as to solve this issue. It would be more than greatly appreciated.
Thank you!
#Marc
sess.php
<?php
session_start();
$_SESSION['test'] = 'test';
include 'sess2.php';
?>
sess2.php
<?php
echo ''.$test.'';
var_dump($test);
?>
session data file value
test|s:4:"test";
Now when I load sess.php it includes sess2.php but the page only displays the vardump which is NULL. This is odd because the data has been written to the session as shown in the downloaded data file value...
Any ideas?
Looks like you're depending on register_globals. That's a hideously BAD thing in PHP which defaults to off these days. Try echo $_SESSION['test'] instead now. As well, such variables are only registered at script startup time/session_start. You'd need to use session_register() (DON'T) to make it take effect during the current execution run
I'm almost embarrassed to ask because it seems so simple, but I can't get it to update.
When the user logs in I set the session vars like
array('users'=>array('timezone'=>'America/los Angeles'));
I can then retrieve the data as follows: $_SESSION['users']['timezone']
and it works fine.
However in the user profile page the user can change their timezone and when I try to update the $_SESSION as follows it doesn't work:
$_SESSION['users']['timezone'] = 'America/Denver';
What am I doing wrong?
--- More code as requested -------
I found that the session variables were being set by a function inside of a class
Here's the function:
function session_var_register($object_name, $var_value)
{
$_SESSION[$object_name]=$var_value;
}
Here's how the function got called:
$gf->session_var_register("users", $user_array)
Users Array looks like array('users'=>array('timezone'=>'America/los Angeles'));
I don't understand why this doesn't work. I was able to get around the problem though by bypassing the function call and just creating the array like:
$_SESSION['users'] = $user_array;
But for knowledge reasons and if anyone else comes along this post, could anyone explain what the function was doing different? There were no errors thrown, just would not allow me to assign anything to the session variable once it was registered via the function...almost acted like it became read_only once instantiated.
Make sure you session_start() on every page that accesses the $_SESSION variable.
Sounds like the code that updates it may not be getting executed. You might try putting some kind of debugging statement before this assignment like an echo to verify that the action is being taken.
Following on from Scott's reply, double checking your session is started is a good "start".
There's a good tip here which you may find useful in debugging.
re-initialize your session id. That way you are sure it has a new spanking id to store your variables.
Are you doing a redirect soon after this code?
Do a session_write_close() before doing a redirect so that session vars are stored again before redirecting.
I have one of those "I swear I didn't touch the server" situations. I honestly didn't touch any of the php scripts. The problem I am having is that php data is not being saved across different pages or page refreshes. I know a new session is being created correctly because I can set a session variable (e.g. $_SESSION['foo'] = "foo" and print it back out on the same page just fine. But when I try to use that same variable on another page it is not set! Is there any php functions or information I can use on my hosts server to see what is going on?
Here is an example script that does not work on my hosts' server as of right now:
<?php
session_start();
if(isset($_SESSION['views']))
$_SESSION['views'] = $_SESSION['views']+ 1;
else
$_SESSION['views'] = 1;
echo "views = ". $_SESSION['views'];
echo '<p>Refresh</p>';
?>
The 'views' variable never gets incremented after doing a page refresh. I'm thinking this is a problem on their side, but I wanted to make sure I'm not a complete idiot first.
Here is the phpinfo() for my hosts' server (PHP Version 4.4.7):
Thanks for all the helpful info. It turns out that my host changed servers and started using a different session save path other than /var/php_sessions which didn't exist anymore. A solution would have been to declare ini_set(' session.save_path','SOME WRITABLE PATH'); in all my script files but that would have been a pain. I talked with the host and they explicitly set the session path to a real path that did exist. Hope this helps anyone having session path troubles.
Check to make sure you are not mixing https:// with http://. Session variables do not flow between secure and insecure sessions.
Had same problem - what happened to me is our server admin changed the session.cookie_secure boolean to On, which means that cookies will only be sent over a secure connection. Since the cookie was not being found, php was creating a new session every time, thus session variables were not being seen.
Use phpinfo() and check the session.* settings.
Maybe the information is stored in cookies and your browser does not accept cookies, something like that.
Check that first and come back with the results.
You can also do a print_r($_SESSION); to have a dump of this variable and see the content....
Regarding your phpinfo(), is the session.save_path a valid one? Does your web server have write access to this directory?
Hope this helps.
I had following problem
index.php
<?
session_start();
$_SESSION['a'] = 123;
header('location:index2.php');
?>
index2.php
<?
session_start();
echo $_SESSION['a'];
?>
The variable $_SESSION['a'] was not set correctly. Then I have changed the index.php acordingly
<?
session_start();
$_SESSION['a'] = 123;
session_write_close();
header('location:index2.php');
?>
I dont know what this internally means, I just explain it to myself that the session variable change was not quick enough :)
Check to see if the session save path is writable by the web server.
Make sure you have cookies turned on.. (I forget when I turn them off to test something)
Use firefox with the firebug extension to see if the cookie is being set and transmitted back.
And on a unrelated note, start looking at php5, because php 4.4.9 is the last of the php4 series.
Check who the group and owner are of the folder where the script runs. If the group id or user id are wrong, for example, set to root, it will cause sessions to not be saved properly.
Check the value of "views" when before you increment it. If, for some bizarre reason, it's getting set to a string, then when you add 1 to it, it'll always return 1.
if (isset($_SESSION['views'])) {
if (!is_numeric($_SESSION['views'])) {
echo "CRAP!";
}
++$_SESSION['views'];
} else {
$_SESSION['views'] = 1;
}
Well, we can eliminate code error because I tested the code on my own server (PHP 5).
Here's what to check for:
Are you calling session_unset() or session_destroy() anywhere? These functions will delete the session data immediately. If I put these at the end of my script, it begins behaving exactly like you describe.
Does it act the same in all browsers? If it works on one browser and not another, you may have a configuration problem on the nonfunctioning browser (i.e. you turned off cookies and forgot to turn them on, or are blocking cookies by mistake).
Is the session folder writable? You can't test this with is_writable(), so you'll need to go to the folder (from phpinfo() it looks like /var/php_sessions) and make sure sessions are actually getting created.
If you set a session in php5, then try to read it on a php4 page, it might not look in the correct place! Make the pages the same php version or set the session_path.
I spent ages looking for the answer for a similar problem. It wasn't an issue with the code or the setup, as a very similar code worked perfectly in another .php on the same server. Turned out the problem was caused by a very large amount of data being saved into the session in this page. In one place we had a line like this:$_SESSION['full_list'] = $full_list where $full_list was an array of data loaded from the database; each row was an array of about 150 elements. When the code was initially written a couple of years ago, the DB only contained about 1000 rows, so the $full_list contained about 100 elements, each being an array of about 20 elements. With time, the 20 elements turned into 150 and 1000 rows turned into 17000, so the code was storing close to 64 meg of data into the session. Apparently, with this amount of data being stored, it refused to store anything else. Once we changed the code to deal with data locally without saving it into the session, everything worked perfectly.
I know one solution I found (OSX with Apache 1 and just switched to PHP5) when I had a similar problem was that unsetting 1 specific key (ie unset($_SESSION['key']);) was causing it not to save. As soon as I didn't unset that key any more it saved. I have never seen this again, except on that server on another site, but then it was a different variable. Neither were anything special.
Thanks for this one Darryl. This helped me out. I was deleting a session variable, and for some reason it was keeping the session from committing. now i'm just setting it to null instead (which is fine for my app), and it works.
I know one solution I found (OSX with Apache 1 and just switched to PHP5) when I had a similar problem was that unsetting 1 specific key (ie unset($_SESSION['key']);) was causing it not to save. As soon as I didn't unset that key any more it saved. I have never seen this again, except on that server on another site, but then it was a different variable. Neither were anything special.
Here is one common problem I haven't seen addressed in the other comments: is your host running a cache of some sort? If they are automatically caching results in some fashion you would get this sort of behavior.
Just wanted to add a little note that this can also occur if you accidentally miss the session_start() statement on your pages.
Check if you are using session_write_close(); anywhere, I was using this right after another session and then trying to write to the session again and it wasn't working.. so just comment that sh*t out
I had session cookie path set to "//" instead of "/". Firebug is awesome.
Hope it helps somebody.
I had this problem when using secure pages where I was coming from www.domain.com/auth.php that redirected to domain.com/destpage.php. I removed the www from the auth.php link and it worked. This threw me because everything worked otherwise; the session was not set when I arrived at the destination though.
A common issue often overlooked is also that there must be NO other code or extra spacing before the session_start() command.
I've had this issue before where I had a blank line before session_start() which caused it not to work properly.
Adding my solution:
Check if you access the correct domain. I was using www.mysite.com to start the session, and tried to receive it from mysite.com (without the www).
I have solved this by adding a htaccess rewrite of all domains to www to be on the safe side/site.
Also check if you use http or https.
Edit your php.ini.
I think the value of session.gc_probability is 1, so set it to 0.
session.gc_probability=0
Another few things I had to do (I had same problem: no sesson retention after PHP upgrade to 5.4). You many not need these, depending on what your server's php.ini contains (check phpinfio());
session.use_trans_sid=0 ; Do not add session id to URI (osc does this)
session.use_cookies=0; ; ensure cookies are not used
session.use_only_cookies=0 ; ensure sessions are OK to use IMPORTANT
session.save_path=~/tmp/osc; ; Set to same as admin setting
session.auto_start = off; Tell PHP not to start sessions, osc code will do this
Basically, your php.ini should be set to no cookies, and session parameters must be consistent with what osc wants.
You may also need to change a few session code snippets in application_top.php - creating objects where none exist in the tep_session_is_registered(...) calls (e eg. navigation object), set $HTTP_ variables to the newer $_SERVER ones and a few other isset tests for empty objects (google for info). I ended up being able to use the original sessions.php files (includes/classes and includes/functions) with a slightly modified application_top.php to get things going again. The php.ini settings were the main problem, but this of course depends on what your server company has installed as the defaults.