+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Development (https://forum.codeigniter.com/forumdisplay.php?fid=6)
+--- Forum: Issues (https://forum.codeigniter.com/forumdisplay.php?fid=19)
+--- Thread: session()->stop() not destroying data (/showthread.php?tid=76220)
session()->stop() not destroying data - beng - 04-22-2020
I may be doing something wrong but I am calling the above
PHP Code:
session()->stop();
Watching in the background, the session cookie does indeed get changed to a new id and the database table is updated with this new session id (and the old row removed / updated) but it is like all the session data is copied across?
Is this a bug or am I being a doughnut...
Thanks
RE: session()->stop() not destroying data - hafijul233 - 04-23-2020
Can u please describe issue little detailed. To destroy session (3.1.11) use $this->session->sess_destroy();
function.Or to regenerate new id use
$this->session->sess_regenerate();
Check session library user guide. Advanced sorry for spelling mistakes.
RE: session()->stop() not destroying data - InsiteFX - 04-23-2020
If you need to destroy the session data use unset()
RE: session()->stop() not destroying data - beng - 04-23-2020
Hi InsiteFX,
Thanks for your reply, to be clear I know I can do any number of "manual" things to remove the data like unset or overwrite etc but coming from ci3 I am trying to utilize all the functionality of ci4.
My concern is, if you read the office docs here:
https://codeigniter4.github.io/userguide/libraries/sessions.html?highlight=session#destroying-a-session
If clearly states this:
"You may also use the stop() method to completely kill the session by removing the old session_id, destroying all data, and destroying the cookie that contained the session id:"
My concern is if this doesn't actually happen it is not only misleading but could also be a security risk if session data unknowingly lives on...
Thanks
RE: session()->stop() not destroying data - jreklund - 04-23-2020
destroy() are an alias for session_destroy.
stop() implements the functionality that the above function lacks unset the session cookie.
It's setting a new cookie and calling session_regenerate_id(true). session_regenerate_id with true are calling session_destroy. So the circle closes.
You call destroy() to log people out, but if you want the user to have a no knowledge of the previous session id you can force them a new cookie with stop().
You can see a more in depth description about it here. https://stackoverflow.com/questions/18262620/what-additional-value-does-session-destroy-bring-when-i-am-using-session-regener/18266353#18266353
RE: session()->stop() not destroying data - beng - 05-11-2020
Hi jreklund,
Again, I know what can be done from a manual point of view I am talking about CI's functionality and more importantly the documentation...
As per my last post the docs clearly say:
"You may also use the stop() method to completely kill the session by removing the old session_id, destroying all data, and destroying the cookie that contained the session id:"
My concern is if this doesn't actually happen it is not only misleading but could also be a security risk if session data unknowingly lives on...
You said:
"stop() implements the functionality that the above function lacks unset the session cookie."
yet the CI docs say otherwise...
So I am asking partly to know the answer and partly to help out, e.g. is this a bug in the code e.g. it's not calling "destroy" as part of the function, or, are the docs incorrect? either way I feel it needs addressing as it could be a nasty security concern...
RE: session()->stop() not destroying data - jreklund - 05-11-2020
Are you still logged in (or other session data intact) after you have executed the stop() function?
You always get a new empty session when you have session set to autoload, but it should be empty. If it's not empty, it's a security risk.
"You may also use the stop() method to completely kill the session by removing the old session_id, destroying all data, and destroying the cookie that contained the session id". This part of the user guide says it's destroyed, but due to the nature of your application you have session on autoload, so they get a new one instantly.
RE: session()->stop() not destroying data - beng - 06-02-2020
(05-11-2020, 09:52 AM)jreklund Wrote: Are you still logged in (or other session data intact) after you have executed the stop() function?
You always get a new empty session when you have session set to autoload, but it should be empty. If it's not empty, it's a security risk.
"You may also use the stop() method to completely kill the session by removing the old session_id, destroying all data, and destroying the cookie that contained the session id". This part of the user guide says it's destroyed, but due to the nature of your application you have session on autoload, so they get a new one instantly.
That's my entire point yes, I am still logged in???
It does indeed instantly load a new session (new session id) but all the session data from the old is copied across hence the entire reason for this thread and question...
I see this as a massive security risk especially based on what the docs say - unless I am missing something here?? Official CI could you shed any light - is this a bug or intentional?
RE: session()->stop() not destroying data - jreklund - 06-02-2020
I haven't used the session library myself, so I can't say how it's actually behaving. But it should log you out.
RE: session()->stop() not destroying data - Crenel - 05-06-2023
I know this is a years-old thread, but there's no resolution mentioned, and I'm having the same problem. stop() is not destroying the data. I'm still logged in after calling it. I've tried stop(), I've tried destroy(), I've tried remove()... this data will not die. (I also can't overwrite it, once I've set a value.)
I also tried the unset($_SESSION['some_name']) approach and still can't wipe out the data.
I'm using the default "out-of-the-box" session configuration, so FileHandler driver, etc. The user guide indicates this will "just work" reliably, but it's reliably just not working.
Either I'm doing something fundamentally wrong architecturally, or something in CI4 is broken (I'm currently on 4.3.3 but I don't think the changes in the one newer version would affect this). Since I can't even unset the value from $_SESSION my guess is that the problem (if it's not my error) is in the FileHandler driver. I'm now going to try switching to the DatabaseHandler driver to see if I can make some progress.
(BTW, after years of sticking with CI3, this is my first CI4 project, and there's a lot to learn. My Web development skills are also rusty and outdated in general. So, I fully recognize that this "bug" may instead be an error on my part.)