CODEWITHSUNDEEP
phpmysqlsession-variables
Andrew L
Andrew L

Reputation: 141

PHP session woes on live but not local

Our development team just moved an app from a local server up to a live site. The app utilizes remote databases that can be written to and utilize MSQLi as well as PDO methods to get and push data to the database.

After updating the connect .inc files to have the proper database credentials the web app works on the back end. Data is getting to the database by way of the forms. However, session variables are not being set for some reason. Now, I am left with the nefarious and almost traditional web dev question:

"why does it work on the local server but not on the live site?"

I did a quick session test where a dummy session variable is set and echoed and it rings like a bell. The issue comes with setting sessions post query. That is to say after the query is run, the data passed is sanitized once more and passed to a session variable. A good example of this follows.

if ($query_dummy = $query_putitthere)
{

$_SESSION ['name'] = $name;
$_SESSION ['date of application'] = $date;
$_SESSION ['certifications'] = $certs;
$_SESSION ['address'] = $addr;


header ('Location: next_page.php');

}

Like a good little PHP developer, OB_start and session_start are both located at the top of the PHP docs and again they worked on the local server with the same code. The only thing I could think to be the issue would be when we changed the credentials for the new DB that something happened but that does not make too much sense since the data is making it to the DB just fine.

I doubt this is a PHP configuration issue because you'd think sessions and PHP's behavior in handling would have to be consistent no matter what version is running. Stranger things have happened however.

The variables are sanitized on the front end by way of msqli_real_escape _string. An example is as follows.

$name = mysqli_real_escape_string($connect, $_POST['your_name']);                                   
$date = mysqli_real_escape_string($connect, $_POST['date_of_app']);         
$certs = mysqli_real_escape_string($connect, $_POST['certifs']);

I realize I may have misspoken when I said they were sanitized one more time before getting to the session. In reality when the sessions are passed, they get sanitized on the second page by way of html_enttites.

The mentality being that MSQLi takes care of sanitation from user input and html_entities takes care of any flukes that may have slipped through the cracks on the back end.

Upvotes: 4

Views: 219

Answers (1)

smitelli
smitelli

Reputation: 7555

It's tough to nail down an exact cause without having a way to replicate the behavior, but here are a few things you might want to double-check:

  • Is the session cookie making it to the browser? This is sent as an HTTP Cookie header, so it would need to happen before your script sends any output to the client.

  • Is the browser's cookie making it back to the server? Writing and reading the cookies across different domains or subdomains could cause problems.

  • How much session data are we talking about, here? I'm not familiar offhand with any size limits on the stored session files, but if you're flirting with php.ini's memory_limit things might get weird.

  • Where are the session files stored on disk? If they're going into /tmp, could a process like tmpwatch be running and nuking the files before you get a chance to read them again? Are the session GC variables in php.ini set too aggressively?

  • Can you find the file for the session in question? What's inside of it? Its content should be parseable with unserialize(), it's also sort of human-readable.

  • Your example shows you setting $_SESSION and then immediately doing an HTTP redirect. Are you being bitten by this ancient, possibly fixed WebKit bug?

Upvotes: 1

Related Questions