401 with Forms Authentication and Roles

[Chuck P]

In asp.net 2.0 with forms authentication and roles it appears that if a user
is authenticated but puts in a url where he is not authorized, forms
authentication redirects him to the logon page. Is their a way where if a
user is authenticated but not authorized I could redirect him to a user
friendly page?
Is their a way to identify that the user was redirected to the logon page?

 

[csharper]

In asp.net 2.0 with forms authentication and roles it appears that if a user
is authenticated but puts in a url where he is not authorized, forms
authentication redirects him to the logon page. Is their a way where if a
user is authenticated but not authorized I could redirect him to a user
friendly page?
Is their a way to identify that the user was redirected to the logon page?

if you have a same user control on every page then you can write the code
that compares the called URL (Request.Url.AbsolutePath) with the
authorizations of the current user and accroding to the result of the
comparig you can redirect him/her to a user friendly page.

 

[Steven Cheng[MSFT]]

Hi Chuck,

From your description, you're using the forms authentication to secure your
ASP.NET web application and is wondering how to redirect those
unauthorized(but authenticated) users to a custom page(other than
login.aspx), correct?

As for this request, I've also met someone else raise this question.
Actually, we can use some code to detect whether the user is an
anonymous(unauthenticated user) or an authenticated but unauthroized(do not
have sufficient permission) one. Here is a code snippet demonstrate this:

====in your login.aspx page=======

protected void Page_Load(object sender, EventArgs e)
{
if (Context.User.Identity.IsAuthenticated)
{
//this is an authenticated but unauthorized user
//redirect it to a friendly page
}
}

=====================

For the custom friendly page, you need to also mark its "authorization"
setting as allow all authenticated user access, e.g.


====allow authenticated user to access that friendly page=======

<location path="friendlyUnauthorizedpage.aspx">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>

=============

Hope this helps you. If you have any further questions, please feel free to
let me know.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Chuck P]

That's was what I was doing but if a previously authenticated user just goes
to the login page (e.g., to logout or change to a different user); they get
the Unauthorized message.

 

[Steven Cheng[MSFT]]

Thanks for your reply Chuck,

Good question. This does be problem when an authenticated user want to
visit the login page (rather than be redirected there). My suggestion is
use the "ReturnUrl" querystring parameter to determine whether the request
is due to an unauthorized redirection(since ASP.NET forms authentication
will append the "ReturnUrl" querystring parameter for unauthorized
redirection request). How do you think?

Please feel free to let me know if you have any other consideration or
ideas on this.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Chuck P]

thanks,
I tried looking at the Global.asax:

protected void Application_EndRequest(object sender, EventArgs e)
{

if (Response.StatusCode == 401 && Request.IsAuthenticated)
{
Response.ClearContent();
Server.Execute(FormsAuthentication.LoginUrl +
@"\NotAuthorized.aspx", false);
}

}


void Application_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError().GetBaseException();

if (ex.GetType() ==
Type.GetType("System.UnauthorizedAccessException"))
{
Server.ClearError();
Response.Redirect("unauthorized.htm");
}


}

Neither of these worked. I guess the FormsAuthentication HttpModule is
doing something or these are more like ACL/OS events. Is the code to the
FormsAuthentication Module available? I'd love to change a few things.

Could I do something with an HTTP Module?

 

[Chuck P]

I think I go it:


protected void Application_EndRequest(object sender, EventArgs e)
{
//Normally you would look for a 401 Access denied. However forms
authentication intercepts the 401 and
//gives you a 302 redirect. So if your authenticated but getting
redirected, it's because you're not authorized.

if (Request.IsAuthenticated && Response.StatusCode == 302 &&
Response.RedirectLocation.StartsWith(FormsAuthentication.LoginUrl))
{

Response.Redirect(FormsAuthentication.LoginUrl.ToUpper().Replace("LOGIN.ASPX", "NotAuthorized.aspx"), true);
}

}

 

[Steven Cheng[MSFT]]

Thanks for your further reply Chuck,

So your current implementation is using the "Application_EndRequest" event
and check both "IsAuthenticated" property and REsponse's StatusCode to
determine the user authorization status.

Actually, my suggestion in previous reply is to put the code logic directly
in the login page's Page_load event(since any unauthorized users are always
expected to be redirected to login page first). You can check the
"User.IsAuthenticated" and Request.QueryString["ReturnUrl"] there to
determine whether the current user is authenticated user and whether he is
redirected to login page because of access denied(rather than manually
navigate to login page).

here is a test code snippet that also works in my test application:
protected void Page_Load(object sender, EventArgs e)
{

if (Context.User.Identity.IsAuthenticated == true &&
Request.QueryString["ReturnUrl"] != null)
{
Server.Transfer("~/AccessDeniedPage.aspx");
}
...................
<<<<<<<<<<<<<<<<<<<<<<

One good point of using Login page is that it won't perform the check for
each ASP.NET request(like what Application_XX event or httpmodule does).

Hope this also helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Chuck P]

Would be nice to keep it all in the logon. However, if you go to the login
page after being authenticated. Say to change the logged in user to a
different user, you would also get redirected.

 

[Steven Cheng[MSFT]]

Thanks for your followup Chuck,

As for the following question you mentioned:

===========
Say to change the logged in user to a
different user, you would also get redirected.
===========

In my login page, I can use "Request.QueryString["ReturnUrl"] != null" to
detect whether it is visited due to unauthorized, therefore, if you
manually or intentionaly visit the login page(there is no such a
querystring item), it won't automatically redirect you, doesn't it?
protected void Page_Load(object sender, EventArgs e)
{

if (Context.User.Identity.IsAuthenticated == true &&
Request.QueryString["ReturnUrl"] != null)
{
Server.Transfer("~/AccessDeniedPage.aspx");
}
..................
<<<<<<<<<<<<<<<<<<<<<<

Anyway, glad that you've got it working and thanks for sharing your
experience.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.