How do I configure what happens when using Authorize(Roles) attribute?

Question

I have an MVC4 project with simplemembership configured. It's all working etc. but I would like to know how to tell it wich controller/action to redirect to when a user is not authorized to view a given page.

For example, if I use [Authorize(Roles="Admin")] and try to view that page with a logged in user that does not have the "Admin" role it redirects me to the login page, even though I am already logged in.

I would like to change this to something else... maybe a 404 or a nice message to say "You are not authorized to view that content".

I've tried googling for just about everything I can think of to do with this but haven't found an answer so far.

Can this be done with the current setup or do I need something else? A pointer in the right direction would be appreciated :)

Answer 1

Try creating a custom AuthrorizeAttribute and override the OnAuthorization method so that you do a redirect to your custom page if authorization fails and to the logon page if authentication fails. Another approach that some people use is to check if the current user is authenticated on the logon page and if they are you can assume they were redirected to this page because authorization failed. In that case display a special message to the user indicating that they are not authorized to access that page. For some applications this may make sense because a user might have multiple accounts and they want to logon to another account where they are authorized to perform the operation. Some of these concepts are discussed in this QA.

Answer 2

This is, unfortunately, a problem with Asp.net as a whole (although it originates from a problem in the HTTP specification), it does not differentiate between unauthorized users and unauthenticated users, even though they seem to go out of their way to talk about the difference. In order to change this behavior, you would have to write a lot of code, and it's just easier to write a custom handler to check if you are already authenticated.

The HTTP standard never intended for a user to be in an "authenticated state". In fact, it doesn't really even know about the concept of a "user". Each page request is intended to carry information independent of the other page requests. The fact that browsers cache this information (or authentication is done by cookie) is irrelevant to what the standard intended.

The standard basically says that the server should issue a 401 if the requested resource is not authorized, and since each request has it's own authorization, the intention a simple pass/fail scenario. There is no concept of an authorized state for the site. The request either succeeds or fails.

I think frameworks like ASP.NET have gone a long way to creating their own authorization/authentication state, but they really should just go all the way here.

You might find this thread enlightening regarding the disagreement among the web community about the exact interpretations.

403 Forbidden vs 401 Unauthorized HTTP responses