Поставщик пользовательского членства + пользовательский CodeAccessSecurityAttribute

Question

Мне поручено создать поставщика custommembership для наших методов для нашего проекта MVC 4.0.

Основываясь на атрибуте ([Authorize]?), Он должен определить, разрешено ли попытке использовать этот метод.

В настоящее время я получил это:

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = true, Inherited = false)] 
public class TestAuthorize : CodeAccessSecurityAttribute 
{ 
    public TestAuthorize(SecurityAction action) 
     : base(action) 
    { 
    } 

    public override IPermission CreatePermission() 
    { 
     throw new NotImplementedException(); 
    } 
} 

Когда я добавляю return new PrincipalPermission(null,null,true) Я ожидаю, что разрешение будет действительным, и пользователь имеет доступ к методу.

Когда я добавляю return new PrincipalPermission(null.null,false) Я ожидаю, что разрешение будет недействительным, и пользователю будет отказано в доступе к методу.

Однако, он останавливается только после того, как я использую throw new SecurityException("You are denied access"), который также заставляет приложение MVC останавливаться, если это исключение не обрабатывается на стороне клиента (используя попытку catch).

Возможно ли, чтобы мы справились с этим исключением в нашем проекте MVC?

как пример того, что мы хотим быть выполнены с использованием атрибутов:

[TestAuthorize(SecurityAction.Demand)] 
public List<string> GetList() 
{ 
    //if access, return new List(); 
    //if no access, return null; 
} 

Answer 1

Довольно, что вы хотите, чтобы унаследовать от AuthorizeAttribute здесь, не CodeAccessSecurityAttribute. В вашем атрибуте вы переопределяете AuthorizeCore и просто возвращаете true, если пользователю разрешено продолжить, и false, если они не имеют права делать все, что он делает. Результат false вызовет ответ HTTP-401 Unauthorised, который ASP.NET автоматически обрабатывает, перенаправляя пользователя на страницу входа, чтобы они могли войти в систему как кто-то с правом доступа, хотя вы можете изменить это поведение, если хотите.

На самом деле вам может даже не понадобиться создавать свой собственный атрибут; если вы используете существующий поставщик ASP.NET MVC memship, или вы можете получить все, что вы используете, чтобы хорошо сыграть с ним, то существующий AuthorizeAttribute будет работать на вас.