Anatomy of ASP.NET Forms Authentication Return URL

Anatomy of ASP.NET Forms Authentication Return URL

  • Comments 2

Consider you are browsing an asp.net web application that uses forms authentication and you are browsing the following url

http://localhost:43751/FormsAuth/default.aspx?var1=test1&var2=test2&var3=test3

Once you time out you will be redirected to the login page with an URL similar to

http://localhost:43751/FormsAuth/login.aspx?ReturnUrl=%2fFormsAuth%2fdefault.aspx%3fvar1%3dtest1%26var2%3dtest2%26var3%3dtest3&var1=test1&var2=test2&var3=test3

The URL is actually built of three parts

1. http://localhost:43751/FormsAuth/login.aspx?

2. ReturnUrl=%2fFormsAuth%2fdefault.aspx%3fvar1%3dtest1%26var2%3dtest2%26var3%3dtest3 and

3. &var1=test1&var2=test2&var3=test3

Ever wonder why we have an encoded version and an un-encoded version of the variables? If you look at the entire URL you will get a feeling that the query-string variables are being passed twice as %3fvar1%3dtest1%26var2%3dtest2%26var3%3dtest3 and var1=test1&var2=test2&var3=test3

It is actually a neat trick to provide access to the original query-string variables in the login.aspx. This is done as a convenience so code on the login page can access the query-string variables sent from the page that triggered the redirect.

Here is how the URL for login.aspx is built.

From the original URL http://localhost:43751/FormsAuth/default.aspx?var1=test1&var2=test2&var3=test3 a search is done for "?" to find the variables that are in the query string. The string after "?" ie. var1=test1&var2=test2&var3=test3 are the query-string variables that the original page has.

Now the entire URL is encoded to get %2fFormsAuth%2fdefault.aspx%3fvar1%3dtest1%26var2%3dtest2%26var3%3dtest3 and this will be passed on as the variable ReturnUrl to the login.aspx

Apart from the ReturnUrl we also append "&" and the variable string that we extracted earlier "var1=test1&var2=test2&var3=test3"

Now if the code in login.aspx page loops thro' the keys in the Request.QueryString variables it will find ReturnUrl,var1,var2,var3. And that exactly is the purpose behind this, you get access to the original query-string variables in the login.aspx without having to parse through the ReturnUrl.

If you disassemble System.Web.Security.FormsAuthentication you will find a function by name GetLoginPage(String,Boolean) :String that builds this string.

loginUrl = loginUrl + "ReturnUrl=" + str2;
if (!string.IsNullOrEmpty(extraQueryString))
{
    loginUrl = loginUrl + "&" + extraQueryString;
}

Once the authentication is done the ReturnUrl variable is used to redirect the user back to

http://localhost:43751/FormsAuth/default.aspx?var1=test1&var2=test2&var3=test3

Bookmark and Share
Leave a Comment
  • Please add 6 and 4 and type the answer here:
  • Post
  • It's actually an horrible hack.

    I have an HTTP module that does some checking in some query string parameters (something like a page flow).

    When the request is redirected to the login page, the parameters will be in that request and fails because the page is invalid with that set of parameters.

    This should not be an opt out feature. This should be an opt in feature. And it should be documented in the MSDN Library.

  • One problem with this is if you actually name one of the original parameters as ReturnUrl (case sensitive here folks). Once you attempt to access that page and you are not logged in, then you are presented with a basic authentication login dialog that does not work with NT accounts or the user accounts on your website.

Page 1 of 1 (2 items)