4

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.

halfer
  • 19,824
  • 17
  • 99
  • 186
Andrew L
  • 141
  • 9
  • post the code that sanitizes – Sharky May 22 '14 at 06:12
  • Assuming you're logging errors, anything in the error logs? Does the code after the `$_SESSION['key'] = $value` bits run? – Phil May 22 '14 at 06:16
  • Yes, there is another header line right after the first snippet and the page properly redirects. I have not had a chance to turn on error logging yet. – Andrew L May 22 '14 at 06:19
  • when you use `mysqli_real_escape_string` have you connected to db? – Sharky May 22 '14 at 06:20
  • I imagine so. The connection header is called and there is no issue connecting or error throwing. (error reporting is turned on in the inc file) and $connect is the connect protocol. Data is making it to the DB as well. – Andrew L May 22 '14 at 06:23
  • Have you checked if the total session is lost or can just not set new values. Check if your app is using the same session identifier in all requests. – AthanasiusKirchner May 22 '14 at 06:25
  • Hmm. More interesting still. A session variable declared anywhere is lost in translation. So to your question Athanasius, yes it looks like the whole session is lost. If by using the same request you mean that the session variables have the same name then yes. Most of them share the same name to reduce overhead and having to keep track of multiple variables (heartburn in other words) – Andrew L May 22 '14 at 06:29
  • Ok try to log the output of session_id () in both skripts after session_start (), just to ensure the app is not the problem, in your case they should be the same (as far as you do not use regenerate). – AthanasiusKirchner May 22 '14 at 17:09
  • Have you checked the PHP settings for the session related directories? Are you using a framework at all? – David Nguyen May 22 '14 at 19:21
  • Mr. Nguyen I don't know that I have access to those files. Are they included in PHP.ini? Also, all the code I hand wrote so not much a framework if we are meaning the same thing. I did use the PDO and SQLi methods so if that is what you are reffering to then yes I have used a framework. – Andrew L May 23 '14 at 02:12
  • Mr. Kirchner, I checked the session IDs and they are the same. Can manually declaring the session id possibly fix the issue, or is that redundant. I stopped the header script and the first page is getting the session variables, but when moving to the second page we encounter the issue. – Andrew L May 23 '14 at 04:26
  • For the session related php settings, please extend your question with information about the session configuration in the `phpinfo()`. – AthanasiusKirchner May 23 '14 at 06:35
  • AndrewL, to speak to a particular user, use their handle. Type the '@' symbol and the first few characters of their name, and you'll get an autocomplete device. If you don't, those users may not see your message, as they may fail to get a notification. – halfer May 25 '14 at 10:25
  • I'm not a fan of `ob_start` at the start of pages - try starting the session without that, and ensure there is no output before any session variables are set. Other than that, I suspect there is not enough info in the post to recreate the problem, so perhaps try creating a new test page that includes the database library etc, and see what small example can be created that replicates the problem. – halfer May 25 '14 at 10:27
  • I know this might seem like a bit of an overkill, but have you tried using a custom PHP session wrapper? I have had numerous PHP session issues in the past and always tend to resolve those by using custom session wrappers if not frameworks. You could possibly try having a look here (http://flylib.com/books/en/2.129.1.167/1/) if all else fails. I would however first try what halfer has suggested though. – Derik Nel May 28 '14 at 06:23

1 Answers1

1

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?

Community
  • 1
  • 1
smitelli
  • 6,835
  • 3
  • 31
  • 53