Sessions being lost very intermittently

[tunnelboy]

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.

[benanamen]

There is no such thing as sendToLog in Php. If you had error reporting turned on you would be getting a notice error of undefined constant like so..

 

 Notice: Use of undefined constant sendToLog - assumed 'sendToLog'

[tunnelboy]

No of course. Maybe I should have made that:

sendToLog; # My function not listed in this code example that logs empty sessions to a log file

[benanamen]

Still an incorrect function call. You need ()

 

Call Function:

 

sendToLog();

 

 

How about try turning on error reporting and looking in the Php error logs. Since you have not posted the function code we have no idea what might be happening there.

Edited March 16, 2018 by benanamen

[mac_gyver]

is your web hosting shared (several accounts on the same server) and using the default /tmp location for the session data files?

[tunnelboy]

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?

[tunnelboy]

Hmmm.. I looked in my php.ini settings and session.save_path is /tmp. Maybe changing that to a folder within my root folder?

[kicken]

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.

Edited March 16, 2018 by kicken

[ginerjm]

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.

[benanamen]

I also have never heard of a shared hosting tmp issue as described. It would be widely known since I would assume most hosting accounts are on a shared server.

 

 

OP, post the sendToLog code.

[kicken]

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

[benanamen]

 

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.

[gizmola]

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.

[gizmola]

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?