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
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.
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