Welcome Guest, Not a member yet? Register   Sign In
Another disappearing session bug?
#1

[eluser]SkiOne[/eluser]
I have a for doing a POST. In the method that receives it, it stores the vars in the post in an array and then stores that array in a session. I am using database backed sessions.

If I go back or forward (i.e. do a page load) the specific variable I am storing get's erased but others I have stored are there.

I checked the timezone set for the server, php and mysql and made sure they are all the same. I have seen the behavior consistently in firefox and most of the time in chrome; haven't even tried IE yet.

I am checking for and logging this variable as the first thing in my controller and I can see that the data is lost at that point but if I look in the db that variable is there before the page reloads.

I have done extensive googling and even tried the Native_session library and still no good.

Any suggestions?

Edit:

On closer inspection it appears to create a new session everytime. I checked the useragent field and set it to 255
#2

[eluser]Stoney[/eluser]
Recently I found a solution.

http://www.hiretheworld.com/blog/tech-bl...conditions
#3

[eluser]WanWizard[/eluser]
That blog post makes me very angry.

First, it is not a race condition, concurrent requests are simply not a part of the design. And this issue is present in all CI versions, not only in 2.0+.

Second, the solution this blog proposes is not a fix but a hack, and one that I have posted on this forum. Something this blog fails to mention.

The issue here is that one request can rotate the session id, while a second request is still running. When the second request finishes, the cookie (which has the rotated id from the first request) will now be overwritten with the old session id, because the second request had no idea it was rotated.

The hack simply remembers the previous session id too, which only solves the issue for concurrent requests that don't run longer than the session rotation time. Reuqests that do run longer will still fail, since you will have two rotations within the timespan of that request, so old previous session id is gone from the database too.

Fixing this permanently requires a complete redesign of the session class.

A correct workaround would be to disable session id rotation on ajax calls, so extend the if in Session:Confusedess_update() to include a check for ajax calls, and return if true.
#4

[eluser]Stoney[/eluser]
Yes it completely fails to mention that you made that session hack. Shame on them.

This solution is not bulletproof, having short session time_to_update with lot of ajax calls in short bursts brings back the problem...

Your workaround seems logical, and it is much easier to hack in.
#5

[eluser]Unknown[/eluser]
I'm the author of the offending blog post, and I've just created an account on this forum to address WanWizard's concerns.

First of all, I should point out that I don't regularly visit this forum, and so am guilty of not reading your version of this 'fix' that you've already proposed. You'll have to take my word on this because I don't have any other proof that I was not aware of your previous post. Also, as I am not in academia any more, I did not feel the need to rigorously define what I mean by "race condition" because I feel that the term adequately conveys what I am trying to describe.

My intention was to document a problem I've run across mainly so that I wouldn't have remember the details the next time I have to deal with it (probably the next time I needed to sync up to the 'develop' branch) and I had hoped that it would be useful to someone else (which is why most people write technical posts).

I am aware that there exists multiple solutions to this class of problem, of which the one I proposed is one of the "standard" ones (I mention that in the blog post), so I'm not surprised that you've also come up with it. I apologize if I have inadvertently duplicated your code down to structure and variable names, and am very surprised to have run across someone who thinks in exactly the same way.

I am also aware of the limitations of this hack, and I do mention that, but I suppose I could have elaborated on it a bit more. I wrote: "With the default session rotation time of 5 minutes, only two session_id values need to be stored because each request round trip time is expected to be well less than the rotation time."

This works for my purposes because I don't expect the requests I handle to continue for that long, and I feel that is the most common case for traffic that CodeIgniter handles (although this is purely speculation on my part).

If you had read my post, you would have seen that I quoted the current 'develop' branch's sess_update function: "if ($this->CI->input->is_ajax_request())", but I did not feel that the solution was sufficient because I've run into situations where two concurrent non-ajax requests occurred. Although you claim that concurrent requests are not part of the design, and you probably don't have to support that case, it is a requirement for me and I appreciate the fact that CodeIgniter allows me the flexibility to handle something that isn't supported by its current design.

Finally, I disagree that a permanent fix would require a redesign of the session class: the other "standard" solution is to keep track of all previously generated session ids (with the requirement that no session id may be reused), and handle any requests using them. This could be implemented by keeping an indexed list of those old session ids, or even by duplicating an existing session id row with the old session id before updating it to the new session id. This should work as long as pointers are kept to the most current session id. An implementation of this could use the same table structure as the solution I proposed. For completeness, I will mention that it should be sufficient to limit the number of old session ids that are tracked so that the total time that is tracked is only slightly greater than the maximum time required to be tracked.

Because this is a standard solution (of which my blog post refers to a degenerate case), you may have very well proposed this before me, and I will apologize again if you did.
#6

[eluser]SPeed_FANat1c[/eluser]
the problem with that is_ajax workaround is that it does not work always. I have tried it on more than one system and on all of them user got disconected from time to time. I have not tried yet samson-htw solution, but maybe I will because I am also making various tries - using 3rd party libs and so on and still cannot find the solution to this.
#7

[eluser]Stoney[/eluser]
Try this:

Code:
class MY_Session extends CI_Session {

    protected $_CI;

/*
* Do not update an existing session on ajax calls
*
* @access    public
* @return    void
*/
function sess_update() {

    $this->_CI =& get_instance();

        if ( !$this->_CI->input->is_ajax_request() ){
            parent::sess_update();
       }
   }
}
#8

[eluser]SPeed_FANat1c[/eluser]
thanks Stoney, I knew this workaround and I have tried it as I said Smile
#9

[eluser]gox123[/eluser]
Hold on a second.. Is this secure?
The whole idea behind updating session_id is to prevent attacker from guessing it by using brute force.

If you want to use above hack, you have to at least make sure that pages containing sensitive information are not accessible by ajax.
#10

[eluser]SPeed_FANat1c[/eluser]
Quote:This solution is not bulletproof, having short session time_to_update with lot of ajax calls in short bursts brings back the problem…

And I found out that making long sessiont time_to_update - makes much less session dissapearrings.

We now use in our application 24 hours session id regeneration. Some might say its unsafe. But did not look at the safety too much, because we are making specific application, for not world wide use and having IP checks, MAC address checks (using adiditional c# program to access computer) and we think we have enough security. Also there is logging where are important things so in case some is trying to hack, we will see in the logs.

This probably will not fit for everyone, but I posted just to consider this. Maybe you are also building site where you can also use your own IP checks or similar.
Also maybe for you default 5 minutes 'too safe' so you might adjust not to 24 hours like us,, but maybe one hour or something.

Also made a test of making session time to update every minute. And then I got 2 seession disconects in 10 mins, so I set back to 24 hour assuming that this really has impact on session dissapear.




Theme © iAndrew 2016 - Forum software by © MyBB