Welcome Guest, Not a member yet? Register   Sign In
session()->stop() not destroying data
#1

I may be doing something wrong but I am calling the above
PHP Code:
session()->stop(); 
using the database driver but the session still lives?

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
Reply
#2

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.
Reply
#3

If you need to destroy the session data use unset()
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#4

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...-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
Reply
#5

(This post was last modified: 04-23-2020, 11:59 AM by jreklund.)

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/1826...3#18266353
Reply
#6

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...
Reply
#7

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.
Reply
#8

(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?
Reply
#9

I haven't used the session library myself, so I can't say how it's actually behaving. But it should log you out.
Reply
#10

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.)
Reply




Theme © iAndrew 2016 - Forum software by © MyBB