How to synchronize lifetime of forms authentication cookie and Asp.Net Session?

Question

I am building an Asp.Net web site that uses FormsAuthentication and standard Session mechanism with configuration like that:

<authentication mode="Forms">
    <forms cookieless="UseCookies" name=".MyAppAuth" loginUrl="~\Login.aspx" timeout="20"/>
</authentication>
...
<sessionState timeout="20" cookieless="UseCookies" />

It seems that lifetime of authentication cookie is not equal to lifetime of the user Session. So Asp.Net doesn't guarantee that

1) Session terminates when user logout,

2) Session doesn't terminates before user logout.

Anybody knows, is there a way to customize FormsAuthentication or\and Session State mechanism to rich these goals?

Answer 1

There's no inbuilt mechanism because the reality is you want to keep users logged in for longer than you want to keep their sessions around for. Also, sessions are not meant to be guaranteed storage, and you should avoid any reliance on data being in session.

Nothing happens on the server when an authentication cookie expires. There is no tracked state.

You could have a 'logout' link and in the handler Abandon the session and SignOut from FormsAuthentication, but there's nothing that forces a user to log out from a website.

Some people like Session, however most hate or come to hate it because its use is abused. Main reasons are Session overuse tends to be the cause of poorly performing servers, and incorrect Session use can create websites that won't scale.

Avoid the use of Session if you can, and if you must use it, observe the recommendations in the MSDN article Improving ASP.NET Performance. Also have a look at Understanding session state modes + FAQ and in particular Q: Why isn't Session_End fired?

Answer 2

I've heard this question many times, my answer is usually "why would you want this?". One does not require the other and their expiration times should be determined using different criteria.

Session state does not require a user to be logged in. An app doesn't even need to use authentication to use session state. You can have a web app where a user is already using session state even before logging in, and still using it after logging out. A "session" here is when a client (web browser) connects to a site, jumps around a few pages, and leaves. Whether a user is logged in or not is irrelevant. If you close your browser, open a new one, and go back to the site, a new session is created. But the server doesn't know you closed your old browser window, so the original session still exists. For scalability (mainly memory) purposes, we expire our sessions and free its memory and session-tracking resources. If a client takes too long to make a new request, the new request will create a new session.

On the other hand, you can use authentication and not use session state at all. I usually start my apps with both session state and viewstate disabled and only enabled them if really needed and on a page-by-page basis (or control-by-control for viewstate).

Session expiration time should be determined by the memory used by each session, the memory available on the web server, number of concurrent users, and other scalability needs. It is usually in the range of a few minutes to an hour.

Authentication is persisted as a cookie on the client and basically doesn't consume any resources the server. Scalability-wise, login expiration can usually be longer than session expiration. In fact a user can stay logged in indefinitely. When authentication expiration is kept shorter, it is usually for security reasons. You don't want your bank web site account to be available to someones else if you move away from your computer for 15 mins, right? You can log into gmail or facebook and select "remember me" and return a few days later and you are still logged in. But of course this would be a new session because no web app should hold on to session data for a few days.

Now, I've seen lots of people use the same length of time for authentication and session expiration. And many also Abandon() or Clear() their session when a user logs out. But they forget however that you still need to manage the case where the user is still logged in but the session has expired (which creates a new empty session on the next request), or when a user's authentication expired but not their session (requiring them to log in again, but carrying around an old un-expired session, possibly with another user's sensitive data). Taking care of these cases is very important, no matter what timeouts you ultimately choose for your application.

Answer 3

The reason I sometimes ask myself this question, is to prevent accessing "expired" session objects. When the session expires prior to login expiration, and the user requests a page that uses data from the session, a nasty null reference exception happens.

You may find this article helpful. It discusses several solutions to detect expired sessions and inform the user about that.