Jump to content

Sessions being lost very intermittently


tunnelboy

Recommended Posts

Page 1:

<?php
session_start();
$_SESSION['test'] = "foo";
?>
<a href="page2.php">Click to continue</a>

Page 2:

<?php
session_start();

if (empty($_SESSION['test'])) {
sendToLog;
}

echo "<pre>";
print_r($_SESSION);
?>

Pulling my hair out. Nine times out of ten this will show the content of "test". But sometimes it doesn't. I've tried it with every browser and device I have and I can't get it not to work. Windows, Mac, iPhone, Android, Chrome, IE, Firefox, Safari. No rhyme or reason. I had my buddy try on his Windows Chrome browser and it consistently doesn't work. I've had others try it and the log file randomly fills up. Sometimes it does, sometimes it doesn't. No pattern whatsoever.

 

I have contacted my host and they say everything is fine on their end.

 

Any ideas?

 

Stumped.

Link to comment
Share on other sites

I have all errors set on and none are being returned.

 

Yes this IS on a shared server, but I'd need to ask whether they are sharing all session data files in /tmp. *If* they were, do you think that would be causing the issue? Should I create my own session id instead?

Link to comment
Share on other sites

Yes, if you are able to, change your session.save_path to a directory exclusively for you. Change it to a directory that is outside of your document root though so you don't end up accidentally exposing your raw session files via the web server.

 

Having your sessions in /tmp along with everyone else on the host means there is the possibility that any of the other websites may wipe out your session file at any time.

Link to comment
Share on other sites

I'd like to see error checking being turned on in this code. I would also like to see how one of these scripts is related to the other!

 

And I seriously question this statement

Having your sessions in /tmp along with everyone else on the host means there is the possibility that any of the other websites may wipe out your session file at any time.

If this were true my complete understanding of how php works would be shattered.
Link to comment
Share on other sites

It's been years since I used shared hosting, so maybe the situation has changed but assuming the follow (which was typical at the time):

- PHP is loaded as an apache module

- PHP runs as the same user for all sites

- All sites dump their sessions into the same save_path (ie, /tmp)

 

Then every site has read/write access to every other site's session files. Someone could deliberately go in and just delete all the save files, but what's more common is that PHP's built in session garabe collection does that.

 

session.gc_maxlifetime

Note: If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path.

So, someone on your server is paranoid about leaving old session data around, as such they configure their sessions using:

session.gc_probability  = 1
session.gc_divisor = 1
session.gc_maxlifetime = 300
Now, any time their script is run it will force garbage collection of old sessions and remove any session that has not been used in the last 5 minutes.

 

So you load up your site and log in, do some stuff. Switch to another tab and spend 5+ minutes doing other stuff. Switch back to your site to do stuff and bam! login screen. Your session just got wiped out by that paranoid user's script.

 

If someone wanted to be malicious they could actually read your session files and gather details about your app and/or it's users. For example, maybe they read your session data and discover you have a $_SESSION['userId']=123 to determine who's logged in and determined your administrator user is ID#9212. They could put this code on their site:

 

session_start();
$_SESSION['userId'] = 9212;
echo session_id();
session_write_close();
Load that file up to make a session file and grab that session's ID. Go to your site and change their PHPSESSID cookie's value to that id and bam! they are now logged in as your administrator user.

 

Now, hosts can certainly protect against this in various ways. Whether they do or not is something you need to determine by either talking to them or testing for yourself. I'd like to assume that the major hosting providers have done work toward limiting what each user can do and guard against these things. Since I haven't used shared hosting since circa 2002 I have no idea the current state of it. I do remember back then on one host I could upload a little script that could enumerate the entire /home directory and read any other users code base. Writing wasn't allowed, but reading is bad enough.

 

The easiest way is to make sure every user has their own session.save_path defined, and this is something you can do yourself by just configuring it if needed. Even better is to have PHP run under different accounts for each user, which can be done fairly easily with a php-fpm setup but may not be as efficient as using the apache module.

 

Some random search results related to this:

Shared hosting for a PHP application

Are PHP sessions stored in /tmp on shared hosting safe?

Shared Hosting: PHP Session Security

Link to comment
Share on other sites

 

I do remember back then on one host I could upload a little script that could enumerate the entire /home directory and read any other users code base. Writing wasn't allowed, but reading is bad enough.

 

 

I dont know about the session part but I can verify the bad shared hosting where you could browse all the other users files back in the day. Like you, haven't been on shared hosting for a very long time.

Link to comment
Share on other sites

Everything stated by Kicken about Shared hosting under Apache/mod_php is absolutely true. With that said, a lot of companies have moved to using fastcgi exactly for those reason -- no way to set it up without people having access to other user's filesystem and data.

 

Without knowing more about the hosting company environment it's hard to know for sure, but it's certainly a viable explanation. I wrote this blog post a long time ago and never really finished off the series I intended, but it talks about Apache/mod_php and how you can look at things like memory use and the way Apache is configured: http://www.gizmola.com/blog/archives/114-Putting-Apache-on-a-diet-how-to-get-a-lean-configuration,-Part-1.html

 

If you have access to a shell on the shared server, you could possibly use some of the techniques in there to examine things, but also phpinfo() will have lots of pertinent info like the way the session handler is configured.

 

One way around this is to use your own custom session handling code, and move your sessions to a database where you wouldn't be prone to the issues brought up in terms of session files being deleted. At that point, however, you would be far better off finding a host that at least gives you a VPS. At this point, I would have to think you would only use shared hosting in a few very select circumstances.

Link to comment
Share on other sites

With that said however, I do have to return to the very valid points that benanamen made about the code snippet. If there are errors, the code isn't going to work. I distrust the word of people who post partial and incorrect code, then point us in a direction that could have absolutely nothing to do with the actual problem.

 

While it could be session files being wiped out, it could also be something entirely different. How about also posting the output from phpinfo() with private details omitted so we can see how the server is configured?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.