menu

Questions & Answers

App using old session file after session_regenerate_id()
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.

Comments:
2023-01-18 23:01:16
Didn't you check the session.use_trans_sid php.ini option? Because according to docs, if it is set to true, and you had made some output before calling session_regenerate_id(), the old session ID continues to be used. See php.net/manual/en/function.session-regenerate-id.php
2023-01-18 23:01:16
@IliaYatsenko Hi, please see my edit answering your question!
2023-01-18 23:01:16
"Still not working after these two edits." - do the server gets restarted?
2023-01-18 23:01:16
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
2023-01-18 23:01:16
@BagusTesa I restarted my server a few times and still nothing. Going to read through Rajan's comment now.
2023-01-18 23:01:16
@Rajan Hi, please see my edits, hopefully with this we can find what is going on...
2023-01-18 23:01:16
When you say that your "app" is still using the old session, can you give us a better idea of the structure of your app? Unless you pass a true argument when regenerating ( session_regenerate_id( true ); ) the old session will still exist, but your browser should have received new cookie settings in the response headers of that script which would switch the session ID for all subsequent http requests. If you're in your browser, look at the Developer tools > Application tab and see what happens to the session cookie when you run the script
2023-01-18 23:01:16
@BenD it's an android app specifically, so when i say it's using the old session, i mean that activities after the login activity are using a different session.
2023-01-18 23:01:16
could you try this on PHP cmd php.net/manual/en/features.commandline.interactive.php and let us see the result
2023-01-18 23:01:16
@marlo here are my results to that i.gyazo.com/f188cecb8447fde4da66bf3d93391f7a.png
2023-01-18 23:01:16
@dan how about from session_start(); to echo json_encode($response);
2023-01-18 23:01:16
@marlo you'd like to to run my own code in the command line?
2023-01-18 23:01:16
@dan sorry, I just tried. Warning: Undefined global variable $_SESSION. I thought that it could be debugged on the interactive shell. my bad
Answers(3) :

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

Comments:
2023-01-18 23:01:16
Hi, I tried your suggestion but my addrelease.php is still seeing 8 as the output: i.gyazo.com/5ac608d8b4d4a667250d1abb3de44328.png and here are some outputs i logged where we can see that the session IDs are still different between files: i.gyazo.com/e1a03dfa9d0644f6e15af5291955233c.png
2023-01-18 23:01:16
See my Edit above.. pls check on multiple browsers and sessions
2023-01-18 23:01:16
for you second edit, I am not sure how to go about testing within a browser given that i only have android app functionality at the moment. I am going to try moving the session_write_close() and let you know.
2023-01-18 23:01:16
Moving the session_write_close() before regenerating the ID results in the following message caught my okhttp: <b>Warning</b>: session_regenerate_id(): Session ID cannot be regenerated when there is no active session in <b>C:\xampp\htdocs\releasesApp\loginuser.php</b> on line <b>7</b><br />
2023-01-18 23:01:16
adding the session_name before session_start() in both files still resulted in different sessions between the files: i.gyazo.com/823c1e9c02ddbf4069e9142891b461ba.png

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

Comments:
2023-01-18 23:01:16
I will look into step 2. Could you explain how I go about steps 1 and 3?
2023-01-18 23:01:16
Step 1: i don't know what all libraries you are using. For Step3: google.com/… . Install your android App on a different app and see
2023-01-18 23:01:16
I'm seeing now that the session appears to be working in Chrome, but not on my phone.

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.