Welcome Guest, Not a member yet? Register   Sign In
UNRESOLVED - The only REAL problem with CI Sessions: Please confirm this Bug
#11

[eluser]WanWizard[/eluser]
This bug still exists in CI 2.0.

I've written a post on this subject a few months ago. Fixing this means modifying half the session library code. I had a first version online, but wasn't happy with it. I'm currently cooking a new version.

What basically has to happen is when the session ID rotates, the old session ID has to be kept in the cookie. You then query the session table with (id = old_id OR id = new_id). If a record is found and the session id == old_id, update the cookie so it's ok again. This works as long as no requests lasts longer than the sess_time_to_update (otherwise you might have two rotations, and you still loose the session).
#12

[eluser]WanWizard[/eluser]
For those who can't wait, the previous version of my session library.

Note that this one stores the previous session_id in the database (the bit I'm not happy with). It contains several other changes as well, so read the header carefully before using this version.
#13

[eluser]theshiftexchange[/eluser]
[quote author="WanWizard" date="1289276533"]For those who can't wait, the previous version of my session library.

Note that this one stores the previous session_id in the database (the bit I'm not happy with). It contains several other changes as well, so read the header carefully before using this version.[/quote]

Thanks for this Wan!!!!! This is awesome.

FYI - If there is a triple request it is still possible to kill the session (I was able to do it in my tests) - but I guess thats going to be pretty rare (to firstly get a triple request, and for it to occur at the '300' sec mark when the session is changed).

Question - why did you change the cookie only write itself when explicitly forced to? If I wanted to revert this to the original (so it is instantly compatible with my current code) - I just need to remove lines 279-282?

Thanks again. Hopefully Ellis Labs looks into this a bit more....
#14

[eluser]WanWizard[/eluser]
That's why I said the entire session class should be rewritten.

Session ID rotation happens based on information in the cookie. In case of multiple concurrent requests, the original cookie is send. If the first request decides it's time to rotate the ID, so will the second (as it's using the last used date in the cookie, instead of the one from the database, which could have been updated in the meantime.

By default, the session library does an UPDATE for every modification to the session variables. It also writes a Set-Cookie to the HTTP header. If you, like me, uses session variables a lot, you will end up with dozens of queries, and a HTTP header which can easily exceed the page in size. Which will have quite a significant performance impact.

To revert my fix, simply change the default value of the write() parameter from FALSE to TRUE.
#15

[eluser]theshiftexchange[/eluser]
Ok cool... I 'get' what you are saying, but what I'm not sure is where do you force the session update in your code to ensure it is done correctly? i.e. where do I call it from?
#16

[eluser]WanWizard[/eluser]
My applications are completely modular.

The application/controllers folder only contains a single bootstrap controller that processes the URI, fetches theme and template information, fetches page layout information, calls module controllers to generate the sections in the template, and displays the page. And after that the session is updated.

The bootstrap is always called, regardless of the URI.




Theme © iAndrew 2016 - Forum software by © MyBB