Lost authentication cookies in SharePoint

Are your users complaining about losing their session in your SharePoint environment? Or do your users complain about being thrown out after a while? This might be the explanation.

When the user has entered his credentials, a cookie is returned to the client (when using claims authentication or other cookie-based authentication methods). This cookie is contained in the header of the requests as long as the user is logged in.

Internet Explorer stores up to 50 cookies per domain. This means that if your code generates a lot of cookies, your authentication cookie might sooner or later be lost (as cookies are handled on a First-In-First-Out basis).

SharePoint list view pages generates cookies (normally 2). After browsing a number of list view pages the browser will receive a high number of cookies. When the number reaches 50, the authentication cookie will be replaced in IE. What the user will experience is that he is "thrown out" (redirected to the log-in page).

If we log on through firefox we can easily see all the cookies generated through firebug

This picture shows the "View all site content page". There are currently 6 cookies from the site domain. After browsing all the list view pages linked from this page we get the following cookies:

As you might see at the picture, the cookies stsSyncIconPath, stsSyncAppName, databaseBtnText and databaseBtnDesc (depending on list type) cookies are written to list relative paths. After browsing a number of pages like these, the number of cookies will sooner or later reach 50. If the user is browsing through IE, the authentication cookie (FedAuth in this example) will be lost.
Note: if you debug the same behavior through Fiddler you will not be able to see these cookies as they are generated client side (through javascripts).

If you do experience this issue you could consider a couple of workarounds:

- Wait for a future fix (the behavior will hopefully be changed in one of the next SharePoint CUs)

- Avoid exposure of list views unless you really need them

- Take a look at how the cookies are generated (hint: ows.js/init.js). Remember that modifying the out of the box files is not supported by Microsoft

Comments

• Anonymous
  June 12, 2012
  Very useful Information. Basically that describes a Problem we are seeing since the install of April 2012 CU. But in our case the FedAuth cookie is still in the Request and number of cookies are far below 20. Only the response looks like the FedAuth cookies was expired what is definitely not the case. Response '302 found' with 'Set-Cookie: FedAuth=; expires=Wed, 31-Dec-1969 23:00:00 GMT; path=/ in the Header. i yet have no clue where the premature re-authentication comes from, cannot not see any App Pool recycles besides the planned ones. the time-span to premature re-authentication is quite random and also different on 2 Web Application.