App using old session file after session_regenerate_id()

Question

session_start();
$_SESSION['user_id'] = 0;
session_regenerate_id();
$_SESSION['user_id'] = 5;

After running the following code, why is my $_SESSION['user_id'] still 0 when I access it later? Am I misunderstanding how session_regenerate_id() is supposed to work? Or is it an issue that I need to address elsewhere?

I can see that two session files have been created in C:\xampp\tmp, but I don't understand why the old file is being used.

My example is me trying to understand why I could not access $_SESSION['user_id'] that I would set after running session_start and session_regenerate_id at the very beginning of my .php file:

session_start();
session_regenerate_id();
$_SESSION['user_id'] = 9; // i am unable to access this because my app is using the old file

Appreciate any help with this.

Didn't you check the session.use_trans_sid php.ini option?

In my php.ini, I have session.use_trans_sid=0 and another suggestion mentioned i do the following as well session.use_strict_mode=1. Still not working after these two edits.

Note: i assume that they are 2 different https/http calls (the two codes starting with session_start() ... ) Can you see what all is stored in the 2nd file in the Session before and after you do the session_start? you can do a print_r($_SESSION) and do it before you regenerate as well I bet there is some code in between your lines that you haven't shared, is doing something to the session_start

I actually simplified my code down to the example in my post, and you can see it here. This way, we are not worried about any other code.

I cleared my tmp folder and ran the code. Here are the resulting files with session_regenerate_id() commented out:

First File - https://pastebin.com/mBhQCrF3

addrelease.php output is 9 for 'user_id'

I commented out the line that sets the 'user_id' to 9 to see what happens next time I log on

Second File - https://pastebin.com/QNJ6S7sY

As expected, a new file with 8 as 'user_id'

Now I will clear the tmp folder (and restart server) again and do the same with session_regenerate_id() in the code. More specifically, this is what loginuser.php will run now:

session_start();

$_SESSION['user_id'] = 8;

session_regenerate_id();

$_SESSION['user_id'] = 9;

$response['success'] = true;
$response['username'] = "test";

echo json_encode($response);
exit;

This time, since we regenerate the id, there should be two files after loginuser.php is finished. I can't tell which one was created first, but we can see that one has 'user_id' set as 9 while the other has 'user_id' at 8:

File 1: https://pastebin.com/ba1vAmjd File 2: https://pastebin.com/H9kDfdvt

After this, the output given by addrelease.php once it's finished is 8.

With the following change to loginuser.php, we can also get an idea of what 'user_id' is before it exits and addrelease.php runs the second session_start() call:

session_start();

$_SESSION['user_id'] = 8;

session_regenerate_id();

$_SESSION['user_id'] = 10;

$response['message'] = $_SESSION['user_id'];
$response['success'] = false;
$response['username'] = "test";

echo json_encode($response);
exit;

I clear tmp folder and restart servers again. This time, 'user_id' output is 10. So we can see that loginuser.php is using the correct file, while addrelease.php does not:

File 1: https://pastebin.com/7MpRMbge File 2: https://pastebin.com/p6RUxH8F

Hopefully I have supplied enough in response to your comment.

EDIT: Also, I don't know if this is significant, but there is a another activity (dashboard activity) between my login activity and my add release activity that does not trigger a .php file.

Answer 1

I think i know the core issue and have the solution as well.

From the json_encode, i assume that some frontend is querying these php files and a json response is sent. So, the session is being written to multiple times.

After writing to the session, IN EVERY FILE that you write sessions to, but PER HTTP/HTTPS request, please do an explicit session_write_close() https://www.php.net/manual/en/function.session-write-close.php .

So, what i mean is that let us assume you have frontendpage1.php that has the html for the user. If you are writing to sessions in this file, do a session_write_close() at the end. Further, if, as a result of an ajax call or something, you have file1.php, file2.php and file3.php used, where they are all writing to the session, do session_write_close() at the end of the last write of the session.

I remember reading that this good practice when sessions are written to frequently.

I had a similar issue with sessions and this worked well

Remember to do a session_start() at the start of each unique browser request/ajax request

EDIT 2nd Option: I think you have a corrupt cookie PHPSESSID . If you try with a browser that doesn't have any cookies set (for the server that is hosting your files), i bet you see the right session values.

Another way to test is, use the same browser, but just add The only thing I can think of is a corrupt cookie PHPSESSID (the default) or whatever cookie you are using, but just add session_name("myStackOverFlowID"); before session_start(); in both these files. the new session_name is not highly recommended: it is just to test.

EDIT: another option

Do the session_write_close() before regenerating the ID

Thanks

Answer 2

Finally, we know that an Android App is involved!

1. Check if any part of the App code is storing cookies, etc., in cache

2. Track time using hrtime(true); (recommended instead of microtime for accuracy) see https://www.php.net/manual/en/function.hrtime.php

3. If possible, clear out the App data on that android phone and test on a different android phone as well

Answer 3

So, after seeing that session was working correctly on my PC browser, I assumed from there that the issue was perhaps purely with how I set up something in my code for the Android app.

As it turns out, my CookieJar implementation was non-persistent. Using PersistentCookieJar instead, I was able to have cookies persist between my activities on the app.

So for anyone having a similar issue, I would suggest reading through this thread and if nothing works, be sure to check your cookie management implementation for the app.