UNRESOLVED - The only REAL problem with CI Sessions: Please confirm this Bug

[eluser]slowgary[/eluser]
EDIT - Will someone from EllisLab confirm this bug? Is this resolved in CI2.0? Thanks.

Hi all,

I've read many posts about the session class being faulty and I have to say that for the most part, they're wrong. I do, however, believe there is a real problem with CI Sessions. In a regular, old school web-app you may never see this scenario. These days this is a more common scenario and one that I am currently facing.

Here it is:

"Bob" has been staring at a web application for 6 minutes, which means his very next request will get a new session ID. He clicks a button that initiates TWO ajax requests. The first request hits the server side which runs through the session ID regeneration. The second request which has already left the client with the old session ID, hits the server and causes Bob's session to be destroyed.

And there it is. This problem is not limited to AJAX requests, but any concurrent requests. The most likely examples I could think of are AJAX heavy applications and serving assets through a controller. I've seen a few proposed solutions which disable the sess_update() call for AJAX requests, but as mentioned this problem is not restricted to AJAX.


If you can add any additional info, or prove that this is incorrect or that some config change will solve the issue, please let me know.

Thanks for reading.

[eluser]CroNiX[/eluser]
To me, it looks like the ajax request WAS the problem in your scenario, but you say it isn't limited to ajax. Had the sess_update() request been ignored on that ajax request, I don't think there wouldn't have been a problem.

Another thing that can help is to not send out more than one ajax request until you receive the first response back. Like using an autocompleter is murder on native CI sessions (where it is sending an ajax request for every keypress...which can be a lot...and close together if you type fast).

I have not had any problems with CI Sessions once I changed the sess_update() to ignore requests made with Ajax.

Its really easy to fix.
1) in application/config/constants.php add:

Code:

define('IS_AJAX', isset($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest');

2) in application/libraries, create MY_Session.php and override the sess_update() method.

Code:

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

class MY_Session extends CI_Session
{

/**
* Update an existing session
*
* @access    public
* @return    void
*/
    function sess_update()
    {
       // skip the session update if this is an AJAX call!
       if ( !IS_AJAX )
       {
           parent::sess_update();
       }
    }
}

[eluser]slowgary[/eluser]
CroNiX,

Thanks for your reply. I have seen this proposed solution, but it is inadequate. AJAX requests transport cookies both ways between client and server, and thus are not truly any different than any other request. The reason that they SEEM to be the problem is that they are commonly issued concurrently.

Indeed, ANY CONCURRENT REQUESTS are capable of creating this scenario. If you read it carefully, you'll see that it has nothing to do with the type of request, but is caused by the fact that the first request causes the session ID regeneration while the second has already left the client with the old session ID.

This problem could just as easily plague an application that serves images via a controller, since the client will request those images concurrently.

[eluser]slowgary[/eluser]
As terrible a solution as it may be, I'm considering just overriding the sessions library and disabling the sess_update() function. I'm less concerned about session fixation than I am about the application seeming very broken to its users.

[eluser]danmontgomery[/eluser]
Why not just increase $config['sess_time_to_update']?

[eluser]slowgary[/eluser]
That doesn't solve the problem. It would increase the amount of time between regenerating a user's session ID, but once that time has passed the bug will still present itself.

[eluser]theshiftexchange[/eluser]
lol - I just realised I've got the same problem as you, and I've arrived at the same conclusion.

Check out my post here: http://ellislab.com/forums/viewthread/90901/P15/

[eluser]InsiteFX[/eluser]
This works!

Code:

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

/**
* ------------------------------------------------------------------------
* CI Session Class Extension.
* ------------------------------------------------------------------------
*
* Add the following define to the bottom of application/config/constants.php
* // Define Ajax Request
* define('IS_AJAX', isset($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest');
*
*/

class MY_Session extends CI_Session {
   /*
    * Do not update an existing session on ajax calls
    *
    * @access    public
    * @return    void
    */
    public function sess_update()
    {
        // if not an AJAX call update the session
        if ( ! IS_AJAX)
        {
            parent::sess_update();
        }
    }

    function sess_destroy()
    {
        parent::sess_destroy();

        $this->userdata = array();
    }
}

// ------------------------------------------------------------------------
/* End of file MY_Session.php */
/* Location: ./application/libraries/MY_Session.php */

InsiteFX

[eluser]theshiftexchange[/eluser]
Hi InsiteFX - unfortunately this code does NOT solve the problem. It is not AJAX requests. And I just tested it on a fresh CI install with your code - the bug still occurs.

You can see how I replicate the error from scratch here: http://ellislab.com/forums/viewreply/821371/

If you follow those steps, then try your code, you'll see the error still occurs (you basically mash F5 on my code and it'll occur).

[eluser]slowgary[/eluser]
If you read the scenario in my first post, you'll see that this problem can happen anytime there are concurrent requests, it has NOTHING to do with AJAX.

I'm a little disappointed that we haven't seen an official reply from EllisLab. Does anyone know if CI2.0 is still plagued with this bug?

Thanks.