Don‘t redirect after setting a Session variable (or do it right)

A problem I see over and over again on the ASP.NET forums is the following:

In a login page, if the user and password have been validated, the page developer wants to redirect to the default page. To do this, he writes the following code:

Session["Login"] = true;

Response.Redirect("~/default.aspx");

Well, this doesn‘t work. Can you see why? Yes, it‘s because of the way Redirect and session variables work.

When you create a new session (that is, the first time you write to a Session variable), ASP.NET sets a volatile cookie on the client that contains the session token. On all subsequent requests, and as long as the server session and the client cookie have not expired, ASP.NET can look at this cookie and find the right session.

Now, what Redirect does is to send a special header to the client so that it asks the server for a different page than the one it was waiting for. Server-side, after sending this header, Redirect ends the response. This is a very violent thing to do. Response.End actually stops the execution of the page wherever it is using a ThreadAbortException.

What happens really here is that the session token gets lost in the battle.

There are a few things you can do to solve this problem.

First, in the case of the forms authentication, we already provide a special redirect method: FormsAuthentication.RedirectFromLoginPage. This method is great because, well, it works, and also because it will return the user to the page he was asking for in the first place, and not always default. This means that the user can bookmark protected pages on the site, among other things.

Another thing you can do is use the overloaded version of Redirect:

Response.Redirect("~/default.aspx", false);

This does not abort the thread and thus conserve the session token. Actually, this overload is used internally by RedirectFromLoginPage. As a matter of facts, I would advise to always use this overloaded version over the other just to avoid the nasty effects of the exception. The non-overloaded version is actually here to stay syntactically compatible with classic ASP.

UPDATE: session loss problems can also result from a misconfigured application pool. For example, if the application pool your site is running is configured as a web farm or a web garden (by setting the maximum number of worker processes to more than one), and if you‘re not using the session service or SQL sessions, incoming requests will unpredictably go to one of the worker processes, and if it‘s not the one the session was created on, it‘s lost.

The solutions to this problem is either not to use a web garden if you don‘t need the performance boost, or use one of the out of process session providers.

More on web gardens: http://technet2.microsoft.com/WindowsServer/en/library/f38ee1ff-bdd5-4a5d-bef6-b037c77b44101033.mspx?mfr=true

How to configure IIS worker process isolation mode: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/26d8cee3-ec31-4148-afab-b6e089a0300b.mspx?mfr=true

Thanks to Frédéric Gareau for pointing that out.

UPDATE 2: Another thing that can cause similar problems is if your server has a name that contains underscores. Underscores are not allowed in host names by RFC 952 and may interfere with the ability to set cookies and thus to persist sessions.

Posted: Aug 03 2004, 05:55 PM by Bertrand Le Roy | with 97 comment(s)

Filed under: ASP.NET

Comments

# August 4, 2004 2:45 AM

Why not use Server.Transfer instead of Response.Redirect especially if both pages are aspx? How can I avoid ThreadAbortException for Server.Transfer?

# August 4, 2004 9:22 AM

Excellent question.
Server.Transfer will not get the right URL in the address line of the user‘s browser. If that‘s acceptable, you can use Transfer, and you save one client/server roundtrip.
Now, Transfer also has a Response.End (and hence a ThreadAbortException), but the code inside Transfer is really just two lines:
Execute(path, null, preserveForm);
Response.End();

So you see that to avoid the exception for Transfer, you should just use Execute instead.
Of course, if you do that, you still need to suppress the output from the first page because both pages will output to the same response (you don‘t need to do that with Redirect because you have two separate requests in this case, and thus two different responses, the first one being thrown away). This can be done by clearing the response before calling Execute or doing some funny stuff with the writer parameter of Execute. Many strange scenarios here ;)

# August 4, 2004 1:19 PM

The scenario becomes more interesting if you‘ve to preserve form collection or pass server control values between pages.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconpassingservercontrolvaluesbetweenpages.asp

http://support.microsoft.com/default.aspx?id=kb;en-us;Q316920

# August 5, 2004 8:55 AM