Session data lost when autoRegenerate = true and multiple simultaneous connections

[ghost]

Created by Simon East, 28th May 2012. (originally Lighthouse ticket #2921):

---

What I did

Set Configure.write('Session.autoRegenerate', true) in core.php

What happened

Session data gets lost.

This, however, occurs only when a browser has multiple simultaneous connections to the Cake app. This often happens when a user:

• Clicks multiple times on a link or form-button (inexperienced users often do this)
• Opens links in multiple tabs in quick succession

Or when a page:

• Contains iframes
• Makes multiple AJAX calls simultaneously
• Loads dynamic CSS/JS/images through a Cake action
• Or CSS/JS/image assets hit a Cake error page

What I expected to happen

Session data to be maintained.

The Problem

The problem is that autoRegenerate does not work when a browser has _multiple simultaneous connections_. In the example below, four images in my page hit 404 errors and produce this bug. The process goes like this:

• The HTML page is loaded, along with any session cookies
• Requests are opened for page assets (such as these images). All requests are made sending the session cookie from the initial HTML page.
• If the autoRegenerate counter hits zero half way through these requests, the bug is triggered. Eg.
  • The images all load a Cake error page. On image 1.3 #3, Cake "regenerates" the session by sending a new session cookie, and deleting the old session's data.
  • Image multiple caching of i18n translations (#1085) #4 is requested using the old session cookie. Cake/PHP detects this as invalid and returns a header deleting the cookie.
• The browser now has no session cookie. Session data is essentially lost.

The Fix

I can't think of an easy fix at the current time, other than to avoid autoRegenerate. (Avoiding broken images would definitely help to some extent.)

One thing that might help is if Cake didn't send a 'delete cookie' request back to the browser when it finds an outdated session ID. So, in the example above, although image #4 would still send the old sess ID cookie, the browser still retains the new cookie from image #3, and future requests would continue as expected rather than all session data being lost.

[ghost]

28th May 2012, Mark Story said:

---

I think not ever having busted images is a good solution too, as you probably screwed something else up in order to get there. If you have a patch I'm willing to review it. Leaving the old session active but auto regenerating sessions kind of defeats the point. Frequently switching tokens is generally done to prevent session snooping. A more effective way to defeat this kind of attack is to use SSL though.

Marking as an enhancement as the feature works except in the case where there are compounded mistakes.

[ghost]

28th May 2012, Simon East said:

---

Yeah, avoiding busted images is definitely a good move, but it took me several hours to identify this as the source of the problem. Unfortunately, images do break when you have user-managed content and production/staging servers don't sync all those assets.

[ghost]

17th Jul 2012, Simon East said:

---

This bug also occurs in other circumstances such as when users double-click links (and yes, it surprises me how much inexperienced users do this).

[ghost]

17th Jul 2013, Costa said:

---

Is there a specific reason for static assets to have to touch sessions? To me static assets should be stateless.

It's unintuitive for a 404 on a static asset = invalidated session.

Can't the asset dispatcher bypass all the session / cookie / auth stuff?

[ghost]

17th Jul 2013, ADmad said:

---

@Costa Assets in your app's webroot are serverd by webserver itself, no php is involved. The dispatcher only serves plugin assests (which too can be avoided if you symlink them into app webroot) and it doesn't trigger any session / cookie / auth stuff.

[ghost]

17th Jul 2013, ADmad said:

---

Only if you have broken links to your assets the request will be handled by php. You can just update your rewrite rules to avoid that.

[lorenzo]

Closing this as the autoRegenerate feature works as expected. End users need to take extra precautions in web apps using this feature to avoid any undesired behavior. Also, my vote would go to removing this feature as it only causes troubles.

[markstory]

I think automatically rotating sessions periodically is useful for certain kinds of applications. It sounds like this was not a good place to use it.

[lorenzo]

Ok, I'll just close this ticket, then.