Find cause of Redirect in 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

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 2

Doesn't the returnUrl querystring value contain any clues?

Cheers
Kev

Answer 3

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 4

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 5

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 6

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.