zen of coding

FU … IE7

Sorry, but this one had me going nuts (not bolts) for 2 days.

When AJAX request was sent to the server in IE7, it would “magically” reset the session ID.
Of course, this would cause serious problems for the end-user.

Mind you, this worked perfectly well in every other browser.
I have searched high and low, lost sleep… pulled out a decent chunk of my hair, until I finally and accidentally stumbled onto a solution.

When dealing with older versions of IE and AJAX be sure to adjust your core.php:

/**
 * When set to false, HTTP_USER_AGENT will not be checked
 * in the session
 */

  Configure::write('Session.checkAgent', false);

The actual change is from default true to false.

p.s. If someone has any idea of the actual effect of this change, I’d be glad to know. So far, other than the fact that IE7 works as expected now, I see no difference.

  • chris

    We dealt with a similar issue. When checkAgent is on, the session code compares the user-agent string (or maybe a hash of it) between requests, and resets the session if they’re different. In our case, it was the Google Chrome Frame that put it’s tag in some requests, not all, resetting the session each time. Use Fiddler or Charles (or server logging) to see what user agents are being sent for ajax vs. non-ajax

  • chris

    Generally people should probably just leave it off. It adds a supposed measure of security, but at the cost of really hard-to-debug issues like this (at least if you don’t know about it). And are you really worried about session hijacking on your app?

  • Aye, I got caught out by this too. Switching it off hasn’t caused any issues.

  • If you secure your app against XSS the session hijacking is almost impossible, so that can be leaved off. CheckUserAgent is another piece of security, which is helpful when you accidentally leave possibility to inject javascript to your site.

  • Jonathan Snook

    I wonder if you were checking in IE8 set to IE7 compat mode. I know there was a bug I filed on that while IE8 was still in beta but thought it was fixed. (I believe I filed it when I ran into this very scenario)

  • teknoid

    @Jonathan Snook

    Unfortunately (or fortunately, depending on how you look at it) IE8 worked perfectly well in both modes. IE7 (using IE tester as well as a real thing, which we’ve manged to dig up via a virtual machine with XP) was the only browser that was causing the issue.

    We all “love” older versions of IE, but still a significant amount of our traffic comes in using IE7, so that was a definite show-stopper.

  • Juan

    I have had the same issue when using safari’s webinspector, so, i always turn it off.

  • I used swfupload and get the same error in sessions. And I found out a solution:

    In beforeFilter of controller:

    function beforeFilter( )
    {
    // $this->action : action has error about session
    if ($this->action == ‘index’)) {
    // $this->params[‘pass’][0]: contain value session id
    $this->Session->id($this->params[‘pass’][0]);
    $this->Session->start();
    }
    parent::beforeFilter( );
    //$this->Auth->allowedActions = array(‘*’);
    }

    In view file: insert this to *.ctp file.

    <input id="id_check_session" type="hidden" value="id(); ?>” />

    • remember submit form with value of sessions

      <input id="id_check_session" type="hidden" value="id(); ?>” />

      p/s: your website get error when I post text have “\id(); ?>”

    • your website get error when I post text have $session->id();

  • please send me an email if anyone have a question or comment from this site for me know

  • teknoid

    @BiBi

    For SWFUpload you simply need to pass your session name as one of the params, to their JS (if you’d call it that)… if I am not forgetting how we did in the past.

  • I think I’ve come across the same issue of session data being reset.

    I have an app that does a usual session-check to allow logged in users to use the site, but some browsers have no session data AFTER logging in (typically IE).

    I’ve been wracking my brains to find a solution. I’ve set Session.checkAgent to false – hopefully that does the trick.

    I figure it has to be something that’s browser specific, and this seems like just the things to wipe the login details of a user.

%d bloggers like this: