koossery.MVCwin includes several types of action filters:
  1. AuthorizationFilter: this action filter helps securing your controller action by restricting access to a particular user or role.
  2. ActionFilter: this action filter is run before and after the execution of a controller action.
  3. ResultFilter: this action filter is run before and after the execution of the result of a controller action.
  4. ExceptionFilter: this action filter provides a way to manage exception during the execution of a controller action.

You also can create your own custom action filters. For example you might want to create a custom action filter in order to implement a custom authentication system. Or you might want to create an action filter that modifies the view data returned by a controller action.

Filters are executed in the order listed above. For example authorization filters are always executed before action filters and exception filters are always executed after every other type of filter.

Authorization filters are used to implement authentication and authorization for controller actions. You can use this filter to secure you controller action by restricting access to a particular user or role

Action filters contain logic that is executed before and after a controller action executes. You can use an action filter for instance to modify the view data that a controller action returns.

Result filters contain logic that is executed before and after a result is executed. For example, you might want to modify a view result right before the view is rendered to the browser.

Exception filters are the last type of filter to run. You can use an exception filter to handle errors raised by either your controller actions or controller action results. You also can use exception filters to log errors.

Authorization Filters

The authorization filter is executed before any other filters. This is important because we may want to be sure that a specific user has sufficient right to run an action. koossery.MVCwin provides a base Authorization filter class (AuthorizationFilterAttribute): to provide your custom authorization filter, you just have to extend the AuthorizationFilterAttribute base class.
The base AuthorizationFilterAttribute class extends FilterAttribute class and implements the IAuthorizationFilter interface. That interface provides a single OnAuthorization method which takes an AuthorizationContext class as an argument. That class represents the context of execution of the attribute. The figure below shows a class diagram.

AuthorizationAttribute.png
Figure 1 : class diagram of Authorization Filter

The AuthorizationFilter attribute contains a list of roles and a list of users. koossery.MVCwin will use those lists to check if a specific user is authenticated and/or is authorize before executing an action.
The listing below shows how to use the Authorization attribute

[AuthorizationFilter(Users = "administrator,manager", controllerName = "LoginController", actionName = "Init")]
 public IActionResult Update()
 {
    //Clearing Errors messages
    this.ClearErrorsAndMessage();

In the sample above, if the user’s role is not ‘adminstrator’ nor ‘manager’, the action ‘Update’will not be executed. Instate, we will be redirected to the action ‘Init’ of the LoginController.

Action Filters Attribute

ActionFilters encapsulates code that is executed before and after a controller action executes.
koossery.MVCwin provides a base ActionFilters class (ActionFilterAttribute) which implements IActionFilter interface and extends the base FilterAttribute class. The image below shows the Action Filter Attribute architecture

ActionFilterAttribute.png
Figure 2 : class diagram of ActionFilter

The IActionFilter interface provides OnActionExecuting (the before method) and OnActionExecuted (the after method) methods.

The first one is executed before the action executes and the second one after the execution of the action but before the execution of the action result. They take as an argument ActionExecutingContext and ActionExecutedContext respectively. You can cancel the execution of the action by providing a value to the Result object contained in the ActionExecutingContext (by default the value is null). If you cancel the action, no other filters higher up the stack will be executed and the invoker starts executing the “after” method for any action filter that had its “before” method called.

In the after method you can’t cancel the action (it already ran), but you can replace or modify the action result before it gets called.

If an exception was thrown by another action filter or by the action method itself, you can examine the exception thrown from your filter. Your filter can specify that it can handle the exception, in which case the action result will still get executed. If the exception propagates up, the result will not get executed.

The usage of the ActionFilter attribute is similar than the Authorization filter attribute. The listing below shows an example

[LogFilter]
public IActionResult Login()
{
	//Getting the login view sessionData
	LoginViewData loginViewData = this.GetSessionData(typeof(LoginViewData).Name) as LoginViewData;

koossery.MVCwin provides a high level of extensibility that helps you to create your own ActionFilter attribute by directly extending the ActionFilterAttribute class.
For further explanation take a look at the dedicated tutorials!

Result Filters Attribute

Result filters are pretty much similar to action filters, except they run after the action method has executed but before the result returned from the action method has been executed.
koossery.MVCwin provides a base result filter class (ResultFilterAttribute) which implements the IResultFilter interface and extend the FilterAttribute class.
The IResultFilter interface defines the OnResultExecuting (the before method) and the -OnResultExecuted (the after method).
To create your own result filter attribute you just have to extends the ResultFilterAttribute class.

ResultFilterAttribute.png
Figure 3: the class diagram of Result Filter

Exception Filter

The exception filters are all guaranteed to run after all of the action filters and result filters have run. Even if an exception filter indicates that it can handle the exception, it will still run. This is useful for logging scenarios in cases where you want a filter to always run no matter what happens so it can log exceptions etc…
One interesting thing to note is that exception filters run after result filters. So we give you one last chance to render something to the user by allowing you to set the action result in the exception filter.
koossery.MVCwin provides the base class ExceptionFilterAttribute which implements the IExceptionFilter interface and extends the FilterAttribute class. The IExceptionFilter defines the OnException method. To provide your custom exception filter, you just have to extend ExceptionFilterAttribute. You can also implement the IExceptionFilter interface and inherits from the base FilterAttribute.
The figure below shows the class architecture of the filter.

ExceptionFilterAttribute.png
Figure 4 : the class diagram of Exception Filter


Last edited Aug 29, 2009 at 11:19 PM by koossery, version 5

Comments

No comments yet.