This is always the case when we write some custom filter without being understanding the sequence which we should be using.
One classic example is to handle custom Unauthorized Access for application permissions at Controller Action level. Say if it user has authorization of application but some of the permission is not allowed and still it executes controller-action then it is a serious issue.
[Authorize]
SomeController
{
[ValidateApplicationPermission]
SomeAction
{
}
}
For. Eg
Using something like this, here we are trying to use filterContext with HttpContext
Solution
Use filterContext with its Result, obey filters and its context.
One classic example is to handle custom Unauthorized Access for application permissions at Controller Action level. Say if it user has authorization of application but some of the permission is not allowed and still it executes controller-action then it is a serious issue.
[Authorize]
SomeController
{
[ValidateApplicationPermission]
SomeAction
{
}
}
Problem Definition:
ValidateApplicationPermission results into 403 access denied leak. It captures access denied and tries to redirect however it is redirecting with executing existing action filter which it should not suppose to be.For. Eg
Using something like this, here we are trying to use filterContext with HttpContext
filterContext.HttpContext.Server.TransferRequest(Entities.Constants.Entities.Content.Something.Home._403.Path .GetSitecoreItemUrlPath());
Solution
Use filterContext with its Result, obey filters and its context.
filterContext.Result = new RedirectResult(Entities.Constants.Entities.Content.Something.Home._403.Path.GetSitecoreItemUrlPath());
