$_SESSION var is cleared 1

[Geates]

I began building a php webpage on my computer running IIS7 with FastCGI/PHP 5.3. I completed several components that make sure of the $_SESSION variable. Once I uploaded it to my server (running apache with FastCGI/PHP 5.2.17) the $_SESSION variable would become empty as soon as I clicked on a link. Interestingly, my other php site on the same server do not have this problem. However, there is one clear distinction. My other php sites have all php files in one folder. The site in question spreads them through-out nested folders.

My other sites:
root/
index.php
fileA.php
fileB.php

This site:
root/
index.php
folderA/
fileA.php
folderB/
fileB.php

Currently, only index.php executes [tt]session_start();[/tt]. Adding it to the other php files doesn't seem to help. I'm assuming that the issue might be a configuration issue, but being Thanksgiving weekend, my host support is not quick to respond. Any idea I may not be considering?

-Geates

NOTE: dew.cilverphox.com. The Array() in the upper left corner is the $_SESSION var. Click on the DEW banner to reload the configuration page and populate the $_SESSION var.




"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[jpadie]

It is probably a session location issue.
My suggestion is this.
Create two files on your server in the root directory of your web server.

ini_set('display_errors',true);
error_reporting(E_ALL);
require 'file2.php';

If (session_id() === ') session_start();
phpinfo();

Now point the browser at file1.php

Hopefully file2 (when included) should throw some errors that will help you debug. Typically the problem is that the session store does not exist or has insufficient permissions. The session store for fastcgi can be set in apache or in local php.ini (from memory)

 

[Geates]

By the time I was able to implement your suggestion, the problem was fixed. I did notice that the session.path had been modified 11/25 at 1:00am. Whether it was created then or the permissions were, i don't know, but things are working again!

Thanks for your input.

-Geates

"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[Geates]

I thought it was fixed, until I tried it in IE. Why must the most widely used browser be a bane to developers!? Actually, Chrome is doing the same thing.

IE7, IE8, and Chrome all have an empty $_SESSION var. FF8 and IE9 (yes, IE) work flawlessly.

No errors occurred when I implemented your troubleshooting method across all browsers. phpinfo() reports identical (as far as observed) configurations.

Still hunting...

-Geates

"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[Geates]

And captured. The inclusion of error_reporting(E_ALL) revealed a notice (usually turned off) suggesting a misuse of a php function. Once corrected, functionality returned across all browsers.

-Geates

"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[jpadie]

Interesting. Can you tell us what function and what misuse? The notice should not have stopped sessions from working unless it was actually being output (which you would have seen on other page requests). Some older designs of apps may need transid to be turned on in php.ini due to whether the browser writes cookies before a page redirect.

 

[Geates]

I assign a token for each new session.

 $_SESSION['token'] = sha1(uniqid(mt_rand[red]()[/red], true));

I was missing the parentheses on the mt_rand function so PHP was interpreting it as an undefined constant. Like I mentioned previously, IE9 and FF8 brushed the notice off. The other browsers threw their hands up and quit.

dew.cilverphox.com/phpinfo.php

-Geates


"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[Geates]

This issue plagued my randomly in a live environment many times. I was able to discover a resolution but I still have no idea what the actual issue was or why it was happening.

The resolution was to remove the use of session_id() and the deprecated session_is_registered. Because all links on the site points to the same php file, index.php?l=xyz; which acts as a control mechanism, I use the following code the determine whether or not the session is valid. Once removed, the random issue of empty $_SESSION ceased...at least for now. Can anyone brainstorm an explanation?

index.php

<?php

session_start();

if (session_is_registered('sid'))
   include "config.php";

switch ($_GET['l'])
{
   case "abc" : include "abc.php"; break;
   case "xyz" : include "xyz.php"; break;
}
...
?>

config.php

<?php

session_destroy();
session_start();

$_SESSION['sid'] = session_id();

... other $_SESSION definitions ...
?>

-Geates

"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[jpadie]

to remove the use of session_id() and the deprecated session_is_registered

the best way to start a session is

if(session_id() == ') session_start();

this is because, as of 4.3.3 an error (warning level) is issued if session_start() is called when a session already exists. testing session_id first means that session_start is called only if it is necessary.

auto-starting sessions is another great way to launch sessions. set this in php.ini.

session problems occur for a number of reasons. most frequently this is a perms problem on the directory specified for session storage. equally prevalent is a non-existent session storage directory. I frequently come across this in php installs on cloud servers where php is installed by apt/yum etc. it's very annoying.

session persistence problems occur (when you have exhausted the above issues) also when you are not using output buffering and your code is throwing errors to the screen. sometimes these errors are output above the doctype and so the browser intelligently hides them. The reason is simply that the error the browser to start parsing content rather than headers, thus all following headers are disregarded. session cookies are set in the headers, so the problem is straight forward.

using calls like session_is_registered() will throw a deprecated error (thus the problem starts) unless you have that error level turned off. assuming you have php >= 5.3.3

using session_id() with an argument may also throw an error if the session cookie has already been sent or the page content has been sent to the browser. this is because a replacement session cookie needs to be set which can only be done in the header output.

This is NOT an advisory for the use of output buffering.

to diagnose this issue the simplest method is to turn off display_errors in php.ini (and reboot). if the issue goes away then start debugging properly. my suggestion is to check the error logs or, if you (like me) prefer debugging through the browser write your own error handling routines to capture all the errors and display them in nice boxes (with back traces) in the footer of your page. or switch on html errors and provide a default doctype in php.ini. whatever works for you.

problems like these should not occur in your production servers because (i) production code should not throw errors as it should be debugged (;-)) and (ii) production servers should never display errors unless they help the end user (as opposed to the debugger). they should log the error of course.

If users have turned off all cookies (and this may well become increasingly prevalent given the e-privacy directive in europe) then your only option is trans-sid. biggest failure point here is for scripts that use header redirects. in such a case you must remember to add the SID to the redirected URL. trans-sid is an ugly ugly thing.

@Geates
the net effect of your code above seems to be to regenerate the session id every time a page load occurs. because there is always a session element called 'sid'. i can't see that session data would ever be preserved in this case (except that there is an oddity in that session_destroy seems not to reset the $_SESSION superglobal, so you might be in luck until they fix that).

why do you need to store the session ID in the session superglobal?

 

[Geates]

I suppose I don't. Your well written explanation and followup question would suggest that session_id() is essentially that of which you ask. I will reconsider implementing session_id() as it seems to be a more elegant way of starting a session.

BTW, it was the <DOCTYPE>. My past practice has been to make it the very first line - even BEFORE php code. I suppose that would screw with the headers? Once I moved it to below the php code and before the <html> tags, all session issue stopped.

Thank you for the explanation. It tells a lot!

-Geates

"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer