3

I have a rather strange problem; there are three pages which are using this cookie - one sets $_SESSION = 0 (as another Stack article suggested my issue might be related to PHP having difficulties with timings so 'pre-creating' the session, then writing to it might help), another file starts the session, changes the session cookie to an array with some useful data in it and supposedly saves it. Only, in this file the session will never actually get written to disk... On the third page, I will try and access the cookie and get an output of '0' (first page).

I've spent a lot of time debugging this and have checked:

  1. That session_start and session_write_close are being used appropriately.
  2. That PHP.ini is set up correctly, with a writable storage path (/tmp)
  3. That PHP is actually using this storage path!
  4. And I've also sat there comparing cookie ID's in browser and on the server to work out when sessions are and are not being created.

I don't see an issue in my code, and as other pages are able to use the session correctly (pages 1 and 3), it is only page 2 which is having an issue.

This is my debugging output from page two, showing the array I tried to write plus the fact that PHP doesn't seem to know what the session ID is, but there are no errors when I call session_start?

bool(true)
session id: 
session file: /tmp/sess_  does not existarray(3) {
  ["user"]=>
  string(5) "kevin"
  ["time"]=>
  int(1472646292)
  ["ip"]=>
  string(13) "178.62.20.247"
}
array(1) {
  ["oscar"]=>
  string(26) "9h8c8fgkscitc7l3m7t18f37u2"
}

And the pertinant code from page two:

<?php
//error reporting
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);
//session starts
session_name("oscar");
var_dump(session_start());

session_regenerate_id();

if (! is_writable(session_save_path())) { throw new \Exception( session_save_path() . ' NOT WRITABLE!'); }




$_SESSION['user'] = $_POST['username'];
$_SESSION['time'] = time();
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];

echo '<pre>';
echo 'session id: ', session_id(), "\n";

$sessionfile = ini_get('session.save_path') . '/' . 'sess_'.session_id();
echo 'session file: ', $sessionfile, ' ';
if ( file_exists($sessionfile) ) {
    echo 'size: ', filesize($sessionfile), "\n";
    echo '# ', file_get_contents($sessionfile), ' #';
}
else {
    echo ' does not exist';
}

var_dump($_SESSION);
var_dump($_COOKIE);
echo "</pre>\n";

session_write_close();

exit();
?>

The output of var_dump(session_start()); is

bool(true)

And if you refresh the page, the output of $_COOKIE changes (as the session ID is changed).

Thank you for any help - I hope I'm not being stupid. I've made a lot of effort debugging this.

EDIT:

This now appears to be an issue with where scripts are in the filesystem. All the files are loaded through one index.php - the ones that don't update sessions (don't work) are located in api/filename.php, whilst, ones that do work are located in ../server/includes/admin/filename.php. (Nb. those paths are relative to index.php)

System: Ubuntu Server 16.04 PHP7 Apache2

CrabLab
  • 182
  • 2
  • 17
  • please check this link it may help : http://stackoverflow.com/questions/19692157/session-variables-not-working-php – rahul Aug 31 '16 at 11:38
  • Not so sure, but isn't `$_SESSION` an array of session data!? `$_SESSION = 0` doesn't make any sense to me personally. Try with `$_SESSION["id"] = 0;` (or whatever you want) and access it in the way you do with any other array. I repeat, not sure and never tried assigning something directly to `$_SESSION` variable. Logic says that if you set $_SESSION variable to something it removes all other array elements of that variable. – Wh1T3h4Ck5 Aug 31 '16 at 11:41
  • @Wh1T3h4Ck5 I'll take a look at that, it wasn't working before I made that change (it's more for debugging) and as it is setting the variable properly I'm not sure there is an issue? – CrabLab Aug 31 '16 at 11:45
  • What does `var_dump($_COOKIE);` show? – Álvaro González Aug 31 '16 at 11:50
  • @ÁlvaroGonzález http://imgur.com/a/8TSJK – CrabLab Aug 31 '16 at 11:52
  • It's strange that your session_id() is empty like that, can you try to regenerate it ? Like first example here : http://php.net/manual/en/function.session-regenerate-id.php – jquiaios Aug 31 '16 at 12:23
  • @Julqas Agreed - I had tried that but nothing (other than the ID) changed. However, it would only change when the third page was loaded. – CrabLab Aug 31 '16 at 12:24
  • I'm out of ideas. At this point, it looks like SELinux or some other security manager is preventing PHP from writing the shared tmp directory. However, I'd always believed that such events should trigger a PHP warning. – Álvaro González Aug 31 '16 at 12:50
  • @ÁlvaroGonzález Agreed. But why would it work one one page but not the other if it was being blocked? – CrabLab Aug 31 '16 at 12:52
  • I think the directory is not writable (could be because of privilege settings, suhosin, restricted paths in php.ini, ...): `if (! is_writable(session_save_path())) { throw new \Exception( session_save_path() . ' NOT WRITABLE!'); }` – Daniel W. Aug 31 '16 at 12:56
  • @DanFromGermany Added the code and isn't generating an exception and sessions are being written to disk by another page. – CrabLab Aug 31 '16 at 12:58
  • I would - comment out all your extra session manipulation logic from your code and just get it to run with 'ordinary' PHP session cookie and session files. That works correctly? Now you can start adding back your 'roll your own session logic' and see where you break it? i.e. always start with something simple that works - then add / change it? – Ryan Vincent Aug 31 '16 at 13:30
  • By "session logic" do you mean all the outputs I'm using to test how PHP is handling the session? @RyanVincent – CrabLab Aug 31 '16 at 13:32
  • In which case, @RyanVincent no - it doesn't work. – CrabLab Aug 31 '16 at 13:34
  • 2
    Leave that in if you want - However, I would make sure that the code works with standard PHP sessions. You may have a simple logic error that is preventing any session handling working. That is why I suggest back to basics. – Ryan Vincent Aug 31 '16 at 13:35
  • Yeah, I just created a new file which has 4 lines in it (start session, write, close session) and still not working. The interesting thing is that the two files that now aren't working are in the same directory, which is different from the two that are working. I wonder why that would cause an issue? – CrabLab Aug 31 '16 at 13:37
  • imo, what you are doing using simple files with just session handling in and bouncing between them is the way to debug this logic. After that you can add you session logic and test it. Once it is working then you can put it back in your real code. – Ryan Vincent Aug 31 '16 at 13:40
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/122306/discussion-between-crablab-and-ryan-vincent). – CrabLab Aug 31 '16 at 13:41

2 Answers2

0

Many thanks to Ryan Vincent who helped solve this over chat.

It stems from the way the actual scripts were loaded - using relative paths from a file higher up the directory. Unfortunately, this caused PHP some issues but didn't generate any errors. By transitioning to absolute paths: DIR . api/filename.php we managed to fix the problem.

CrabLab
  • 182
  • 2
  • 17
  • Can you please elaborate about that? Your code does not use file paths anywhere I can spot :-? – Álvaro González Sep 01 '16 at 11:40
  • Sure. It's actually file paths used to load this file via includes that were the problem. I'll update. – CrabLab Sep 01 '16 at 11:44
  • Failed includes trigger warnings. The problem is possibly that your PHP installation has error reporting disabled system-wide and you're enabling it *inside* the included file. This illustrates the importance of providing actual code when you ask questions here :) Whatever, glad you got it sorted out. – Álvaro González Sep 01 '16 at 12:30
  • Yeah, that is true. I did try to include code but given that the file which was using relative directories is 500 lines AND I didn't see how it could be the problem I thought I'd save you the trouble :) Hah! – CrabLab Sep 01 '16 at 13:28
-2
session_start();

Should be at the top of the script and it should be on top of every page where session variables are used if the included files on top does not contain session_start().

teo van kot
  • 12,350
  • 10
  • 38
  • 70
Gandharv
  • 110
  • 6
  • 1
    This is the case - indeed, it was the first thing I checked for (and is stated in the question) – CrabLab Aug 31 '16 at 11:57
  • 7
    I doesn't need to be "on top". It's enough if it's located before HTTP headers have been sent and (of course) before session data is used. – Álvaro González Aug 31 '16 at 12:03