redirect on failed authorization in ASP.NET 2.0

[bryanp10]

This is driving me crazy. How do I redirect a failed AUTHORIZATION to
a custom page in ASP.NET 2.0?

All failed authorizations are going to my loginUrl, which is next to
useless. I want an error page that says WHY a user can't access a URL.
This seems like it should have been an obvious feature for 2.0...
alas, it appears even harder now!

I have tried looking at the Response.StatusCode in
Application_EndRequest (or Global_EndRequest), which is a solution
posted in other threads on this topic. But it does NOT work in ASP.NET
2.0. The StatusCode is always 302 for failed auth.

 

[Dominick Baier [DevelopMentor]]

there are two approaches for this:

- prepare your login page to get called even when the user is already logged
in (which would be a indicator for a 401) and render according to this
- inject a HttpModule before the FormsAuthModule and inspect the status code
in EndRequest - this allows to "see" the 401 before FormsAuth converts it
into a 302.

 

[bryanp10]

Unfortunately, neither of these solutions make much sense to me...

- prepare your login page to get called even when the user is already logged
in (which would be a indicator for a 401) and render according to this

Eh? There is no way to detect whether the page is being called because
the user is not logged in yet or the user is not authorized. That's
the root of the problem.

- inject a HttpModule before the FormsAuthModule and inspect the status code
in EndRequest - this allows to "see" the 401 before FormsAuth converts it
into a 302.

Now this I just don't get... If I inject a custom module before
FormsAuth, how do I know the user has access to the site at all? They
won't even be authenticated yet?!?

I am adding user roles to identity in Application_AuthenticateRequest
(as suggested by the MSDN article on using Roles with Forms
Authentication). Will this event still fire before my module runs?
When does the Response.StatusCode change to 401?

Seems like a good time to mention that neither "How to: Create Custom
HTTP Modules" or "Introduction to Http Modules" in MSDN actually
mention how to modify the order of execution of modules. How is this
done?

 

[Dominick Baier [DevelopMentor]]

inline

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

Unfortunately, neither of these solutions make much sense to me...

Eh? There is no way to detect whether the page is being called
because the user is not logged in yet or the user is not authorized.
That's the root of the problem.

There is - the Context.Request.IsAuthenticated property tells you if the
user is authenticated.

Now this I just don't get... If I inject a custom module before
FormsAuth, how do I know the user has access to the site at all? They
won't even be authenticated yet?!?

Again - if the user is authenticated, but you see a 401 - this is an indicator
of "unauthorized"

I am adding user roles to identity in Application_AuthenticateRequest
(as suggested by the MSDN article on using Roles with Forms
Authentication). Will this event still fire before my module runs?
When does the Response.StatusCode change to 401?

If you are adding roles to your user the recommended event in 2.0 is PostAuthenticateRequest.

The UrlAuthorizationModule sets the 401 in the AuthorizeRequest event which
runs after PostAuthenticateRequest. This module also calls CompleteRequest()
which short-circuits the whole pipeline and directly jumps to EndRequest.
Thats why you can't see the 401 without injecting code before FormsAuth handles
EndRequest.

Seems like a good time to mention that neither "How to: Create Custom
HTTP Modules" or "Introduction to Http Modules" in MSDN actually
mention how to modify the order of execution of modules. How is this
done?

By adding a <clear /> element in your local <httpModules> config section
and adding the modules manually back. You can copy this element from global
web.config. Modules are executed in the order they are registered...