7

A client wants to change the timeout duration for users logged in through the shell/experience editor. I found 3 different places that seemed to reference timeouts for a user in Sitecore.

<sessionState mode="InProc" cookieless="false" timeout="20" sessionIDManagerType="Sitecore.SessionManagement.ConditionalSessionIdManager">

<setting name="Authentication.ClientSessionTimeout" value="20" />

<forms name=".ASPXAUTH" cookieless="UseCookies" timeout="20" />

I changed each to 1 while leaving the others at their value to see what would happen. Changing the forms element's timeout to 1 caused the user to be logged out after a minute. I could not tell what the others did exactly and reading the comments didn't really clear it up. I found a link stating that the sessionState element's timeout clears a session while forms keeps the user authenticated. I would like to know the differences between these 3 values and whether or not they should be kept in sync.

1 Answer 1

7

They are all slightly different things and do not necessarily need to be in sync:

<forms name=".ASPXAUTH" cookieless="UseCookies" timeout="20" />

Is a Forms Timeout and is the length in time that the auth cookie is valid. Once this time is reached, the cookie will no longer be valid and the user will no longer be authenticated.

<sessionState mode="InProc" cookieless="false" timeout="20" sessionIDManagerType="Sitecore.SessionManagement.ConditionalSessionIdManager">

Is a Session State Timeout and is the amount of time a provider is expected to hold data in memory/SQL (in-proc/sql session state). After this timeframe, the data will be removed regardless of if the user is authenticated or not. The timeout counter will be reset after each request.

<setting name="Authentication.ClientSessionTimeout" value="20" />

Is the Sitecore Authentication Timeout and is the length of time that Sitecore considers an authenticated session is valid for. This setting is only considered relevant for logins to the Sitecore Client.

The noteworthy difference between ClientSession Timeout and the Forms Timeout is the scope of the users. Forms Timeout will be in effect for any and all Form authentication since it's application bound while the ClientSessionTimeout is specific to the Sitecore Client. If your site does not contain any additional Forms Auth than what is used for a standard Sitecore Client user, then the Forms Timeout may match the ClientSession Timeout, but if you are using a different provider for Sitecore Client authentication (LDAP) or have any other Forms on the site that would require different timeout windows, they can be set to different values.


Edit: After @Teeknows comment about ClientSessionTImeout being set to 1 and the other values being set to 20 and not getting logged out, I looked a hair further. From what I can gather, DomainAccessGuard does some checks if your session is valid within/for the domain. It looks like one of the few times the Authentication.ClientSessionTimeout is checked is only after DomainAccessGuard checks for an active session and doesn't find one which (I could be wrong) implies that it was invalidated and removed, or the Sitecore.Support.SessionTimeout.ExpirationAgent disposed of it (https://kb.sitecore.net/articles/345947). This may be why setting ClientSessionTimeout to less than FormsTimeout may not necessarily trip a re-auth, especially if this is only being used by a single user at the time (not managing multiple sessions against a license/domain).


Sources: https://getfishtank.ca/en/blog/setting-session-timeouts-in-sitecore-7 https://stackoverflow.com/questions/17812994/forms-authentication-timeout-vs-sessionstate-timeout

1
  • This is pretty good info but can you explain why setting Authentication.ClientSessionTimeout to 1 while the other 2 are set to 20 does not log me out of the shell/experience editor after a minute of being idle? I'm seeing this in an instance that is pretty much stock.
    – Teeknow
    Oct 30, 2017 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.