Redirecting to custom 401 page when "Access denied" occures within an ASP. NET applicatio

If you have an ASP. NET application with authentication mode set to Windows:

 <authentication mode="Windows"/><authorization><deny users="?" /></authorization>

Then all Windows users can access your pages but those without Windows login (from internet) will receive an ASP. NET "Access Denied 401" page. I have decided to replace this default message with some custom page. after couple of hours Googling, I found out that this is a very common problem and all the workarounds which seem to be reasonable does not work. here are some of them:

1. Use a custom error page inWeb. config:

   <customErrors defaultRedirect="ErrorPage.asp&shy;x" mode="On">    <error statusCode="401" redirect="AccessDenied.aspx" />    </customErrors>

   This works finestatusCode="404"But not with 401.

2. Try to catch an unauthorized request in one of the application events inGlobal. asax. cs:

   protected void Application_AuthenticateRequest(Object sender,    EventArgs e)    {    if (!Request.IsAuthenticated) Response.Redirect(    "AccessDenied.aspx");    }

   It is also useless, because even the browsers with valid credentials make two posts, one without credentials and havingRequest.IsAuthenticated=falseAnd the other one with credentials and havingRequest.IsAuthenticated=true. Browsers without credentials make only one post. It means you are not able to determine if the first post havingRequest.IsAuthenticated=falseComes from an unauthorized browser or not.

The problem

Then I found an answer from a Guru at microsoft. public. dotnet. framework. aspnet. security newsgroup.

That's correct. there's no way around that. the way wininet authentication works is that if the resource you are requesting does not allow anonymous access, a 401 is sent back to the browser. if the resource is using Windows Integrated authentication and the browser is configured to automatically send credentials, the token is sent back and the user is authenticated. in the case of Basic authentication, a login prompt is displayed and the user must log in.

If you intercept the 401 and redirect somewhere, you hijack the browser's ability to challenge. There is no way around that.

Jxx Cxxxxxx, MCSE, MCSD [MSFT], Developer Support, ASP. NET.

Resolution

That was also the result of my research. The whole thing works like this:

1. The browser sends request without credentials to the server.
2. Server rejects this request and answers with "401 Access Denied ".
3. Browser recognizes 401 and if it has appropriate credentials does not show this message. The second request with credentials will be posted. The requested page will be sent to the browser.
4. If the browser hasNo credentialsThe second post will not take place. The specified ed "401 Access Denied" will be shown.

The workaround is to manipulate the content of "401 Access Denied" response. the browser uses the header of this response to determine 401 case. it means we can manipulate the HTML content without influencing the whole challenge. for instance we can add the following code inApplication_EndRequestEventGlobal. asax. cs.

  protected void Application_EndRequest(Object sender,EventArgs e){HttpContext context = HttpContext.Current;if (context.Response.Status.Substring(0,3).Equals("401")){context.Response.ClearContent();context.Response.Write("<script language="javascript">" +"self.location='../login.aspx';</script>");}}

Now, the whole thing works like this:

1. The browser sends request without credentials to the server.
2. Server rejects this request and answers with "401 Access Denied" Header + our JavaScript.
3. Browser recognizes 401 and if it has appropriate credentials does not show this message. our HTML will not be rendered and JavaScript will not be executed. the second request with credentials will be posted. the requested page will be sent to the browser.
4. If the browser hasNo credentials, The second post will not take place. the specified ed "401 Access Denied" will be shown. our HTML will be rendered and JavaScript will be executed. the client side redirection will take place. the browser will show a custom 401 page.