Find cause of Redirect in ASP.NET? - asp.net

Question

I'm trying to put in an exception in my web.config so that one page does not require authentication. However, it still redirects to the login page.
The question isn't how to setup the web.config. Why? Our system (for better or worse) has a bunch of instrumentation besides the web.config. We have global.asax and custom HttpHandlers. The code base isn't huge, but there's a lot of potential causes for the redirect.
What I do want to know is how to best determine the cause of the redirect. Is there some way to find out what code triggered the redirect?

Answer 1

If you can debug the app, starting from HttpApplication.BeginRequest in global.asax and stepping through System.Web's reference source would be the brute force way.
Alternatively, set a breakpoint on HttpResponse.Redirect(string, bool) and follow the call stack - I doubt there's any other ways that the runtime uses to redirect a request.
If that doesn't turn anything up (or you can't debug), and since the brute force method is likely to lead through a lot of code - and it seems your problem is security related - you could probably just hook HttpApplication. AuthenticateRequest and HttpApplication. AuthorizeRequest, (and it's associated Post* events) and seeing what things look like there.
If you're using Forms Authentication, I happen to know that the FormsAuthenticationModule looks for a status code of 401 at HttpApplication.EndRequest to decide whether to redirect the request. Anything that sets 401 (access denied) will result in a redirect - not the 401 being returned to the browser.

Answer 2

When a request is made to an asp.net page requiring authentication, asp.net redirects to the specified login page with supplying a ReturnUrl querystring argument identifying the original requested page by default. While this ReturnUrl is configurable, if you have not modified the configuration, it's presence should indicate that authentication failed.
In this case, you should be focused on troubleshooting the authentication settings for the page. Gordon Bell's answer looks good for this.
<system.web>
...
</system.web>
<location path="NoAuthNeeded.aspx">
<system.web>
<authorization>
<allow roles="*" />
<allow roles="?" />
</authorization>
</system.web>
</location>

Answer 3

Also, if this is only happening in your production app, you might be able to find out what is going on using WinDBG. Loosely following this article you'd do the following:
Fire up WinDBG and attach to the w3wp process
WinDBG will breakpoint, so do a .loadby sos mscorwks which will load the SOS module
type sxe clr to breakpoint on CLR exceptions
type g to continue on
Now your app will break on any exception. Since Response.Redirect typically throws a ThreadAbortException it might be a simple way to break. Then do a !printexception to get the stack trace. You can also do a ~*e!clrstack if my WinDBG foo isn't failing me to see the managed stack for all the threads currently executing.
Note that you freeze the w3wp process while you are broken in, so be quick!
Hopefully you can use another method instead, but if all else fails, this might help you get started.

Answer 4

Have you tried turning on Tracing? That may help.
How are you specifying the page doesn't require authentication, like:
<system.web>
...
</system.web>
<location path="NoAuthNeeded.aspx">
<system.web>
<authorization>
<allow roles="*" />
<allow roles="?" />
</authorization>
</system.web>
</location>

Answer 5

Put a breakpoint at the beginning of each HTTP handler and notice which one is the last invoked handler before the redirect occurs. You will probably find the cause of the problem in that one.

Answer 6

You can use the following method to find a redirect in your own code:
Open the Exception Settings window and search for "threadabort". Check the checkbox for the ThreadAbortException. Now, when a redirect is executed from code, your debug session will enter break mode.
But since you are talking about the authentication in the web.config, it's highly likely that the issue is there, and not in the code.
Double-check that all the authorization elements like mentioned in HectorMac's answer are correct.