Attributes are based on the System.Web.Mvc.FilterAttribute class.
Their primary purpose is to analyse
information coming into the controller, especially HttpContext, and determine
if it meets certain criteria
=> basically perform some logic
before and/or after an action method is executed.
MVC Framework support five different
types of filters:
The ActionFilterAttribute class implements both the IActionFilter and IResultFilter interfaces.
·
This
class is abstract, which forces you to provide an implementation.
The AuthorizeAttribute and HandleErrorAttribute classes contain useful features and can be used without creating a derived class.
In order for a .Net class to be treated as an MVC filter, it must implement IMvcFilter – you can do this directly or derive from FilterAttribute class.
To implement a custom Authorization Filter
Derive from AuthorizeAttribute
and override the AuthorizeCore
method:
public class AuthorizeFilterAttribute : AuthorizeAttribute
{
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
// Logic
here
return true;
}
}
Some devs will implement IAuthorizationFilter themselves in order to gain access to
the AuthorizationContext (contains more info like routing data
and which controller/action is being called).
This is not recommended because:
- Best not to include controller/action specific logic in the Authorization filter
- Doing so breaks the seperation of concerns and causes testing problems
- Keep it simple; let the context of what is being authorized come from where the attribute is applied.
- Put global authorization concerns in the Authorization filter; e.g. a request from a certain domain should always be denied
- Keep the security checks as close as possible to the resource being secured -> this way no matter how the user got to the resource, there will always be a security check.
Using the built-in Authorization Filter
Can provide an authorization policy by specifying two public
properties: Users and Roles
[Authorize(Users = "admin, spoc", Roles
= "Manager, DeckHand")]
public class AccountController : Controller
This will authorize users admin and spoc
to access the Account controller, as long as they are in at least one of the Roles Manager
or DeckHand.
Note that there is an implicit restriction here that the
above users must be authenticated.
=> if no Users or Roles are specified, then any User, in
any Role can access the controller.
If the filter denies the request, the MVC framework will
return a 401 Not Authorized response, which is then internally converted to a
302 redirect to the login page and the browser will respond to this by
prompting the user for credentials.
The 401 to 302 conversion is handled by Open Web Interface
for .Net (OWIN) components.
In previous versions; this redirect was handled by defining
a loginUrl in the <authentication> element of web.config.
SECURITY
WARNING: If you ever attempt to write your own Account controller, be
aware of the risk of Open
Redirection Attacks that arise due to the 401 to 302 redirection process.
