모델 뷰 발표자 디자인 패턴을 사용한 보안 및 역할 인증

Question

보안 및 역할 권한 부여가 모델보기 표현 자 디자인 패턴에 가장 잘 맞는 곳은 어디입니까?

는 특정 인터페이스를 구현하기 위해 보안을 구현하는 모든 페이지에 대한 있을까, 발표자 수준

public abstract class Presenter<TView> where TView : IView 
{ 
    public TView View { get; set; } 

    public virtual void OnViewInitialized() 
    { 
    } 

    public virtual void OnViewLoaded() 
    { 
    } 
} 

public abstract class AuthorizationSecuredPresenter<TView> 
         : Presenter<TView> where TView : IAuthorizedView 
{ 
    public override void OnViewInitialized() 
    { 
     View.AuthorizationInitialized(); 
     base.OnViewInitialized(); 
    } 

    public override void OnViewLoaded() 
    { 
     View.AuthorizationInvoked(); 
     base.OnViewLoaded(); 
    } 
} 

이 될 것이다 내부 처리 그리고

public interface IAuthorizedView : IView 
{ 
    IUser user; 
    void AuthorizationInitialized(); 
    void AuthorizationInvoked(); 
} 

의 라인을 따라의 IAuthorizedView 말을 내 그것에 대한 첫 번째 아이디어는 이것이 내게 남을 유일한 질문입니다. 웹 기반에서 전적으로 이동하여 서비스 수준에서 권한 부여가 필요한 모든 유형의 API를 추가하면 액세스 검사의 중복이 많이 발생하거나 완벽하게 처리됩니다. 두 번 검증 할 수 있으며 앞쪽으로 설계해야합니까?

Answer 1

다음은 고려해야 할 사항입니다.

데코레이터 패턴을 사용하여 개체 호출을 개별적으로 인증 할 수 있습니다.

의 당신이 다음 클래스가 있다고 가정 해 보자,이 설정이되면

public class MyServiceDecoratorBase : MyService 
{ 
    public MyServiceDecoratorBase(MyService service) 
    { 
    } 
} 

수행 할 수 있습니다

public class MyService 
{ 
    public virtual void DoSomething() 
    { 
     //do something on the server 
    } 
} 

당신은 다음과 같이 기본 생성자를 구현하는 기본 장식을 만들 진행할 것을 다음과 같이 인증 데코레이터를 작성하여 실제로 꾸미기 시작합니다.

public class MyServiceAuthorizationDecorator : MyServiceDecoratorBase 
{ 
    private readonly MyService _service; 
    public MyServiceDecoratorBase(MyService service) 
    { 
     _service = service; 
    } 

    public override void DoSomething() 
    { 
     //TODO: Authorize the user here. 
     _service.DoSomething(); 
    } 
} 

이제 주 수업이 끝났습니다 ... 어떻게이 모든 것을 부를 것입니까? 쉬운!

MyService service = new MyServiceAuthorizationDecorator(new MyService()); 
service.DoSomething(); 

이제 인증 로직이 기본 서비스 (또는 객체) 로직과 완전히 분리된다는 장점이 있습니다. 왜 이것이 중요한가? 테스트 가능성. 인증 로직과 독립적으로 주 서비스를 테스트 할 수 있습니다. 이것은 열기/닫기 원칙에 해당합니다.

자, 여기 귀찮은 방법으로 성능을 계산하고 싶다고 가정 해 봅시다. 데코레이터를 추가하십시오! 벌채 반출? 또 다른 데코레이터! 그들은 모두 그렇게 묶일 수 있습니다. 물론, 당신이 더 많이 추가할수록 더 무거워 지지만, 그것이주는 이점 때문에 가치가 있다고 생각합니다.

댓글?

Answer 2

보기는 UI 만 처리해야합니다. 필요한 경우 대화 상자/양식/컨트롤을 설정해야합니다. 사용자가 권한 부여를 시도하면 데이터를 발표자에게 넘겨줍니다.

그러면 표현자는 모델에서 노출 된 API와 모델을 사용하여 해당 데이터를 가져와 유효성을 검사해야합니다.

내 CAD/CAM 응용 프로그램에서 실제 API는 내 응용 프로그램의 가장 낮은 유틸리티 어셈블리에 있습니다. 나는 주위를 감싸고 인터페이스하기 때문에 만약 보안 API가 상위 레벨에 있다면 다른 것을 보지 못할 수도있다. 유틸리티는 입력 된 정보가 유효한지 여부와 그 사람에게 부여 할 보안 수준을 알려줍니다.

더 자세한 내용은 사용중인 보안 API에 따라 다릅니다.

Answer 3

디자인에 문제가없는 것 같습니다. 당신의 결론 질문에 대한 같은 ...

우리가 기반 전적으로 웹에서 이동 검사 액세스의 중복을 많이가 끝날 것이라고 서비스 수준 에 권한이 필요 API의 모든 유형을 추가 한 경우 또는 은 두 번 완전히 을 확인하는 데 적합하며 앞면이 인 경우 설계해야합니다.

대답은 단호하다 예 - 당신도 이러한 검사 반 중복 경우에도, 더 자주보다 사용 권한을 확인 할 수 있습니다. 나는 (역할 기반 보안 요구 사항) 일반적인 웹 애플리케이션의 보안을 확인할 것 적어도 세 번 생각할 수 있습니다 :

• 첫째, 당신의 비즈니스 계층 내부

  - 보안을 위해 상관없이 적용되지 않는다 실행 컨텍스트.

• 둘째,보기 자체 (또는 발표자)를 만들 때 보안상의 이유로 사용자가 권한을 가진 기능 만 볼 수 있도록해야하며 시간을 낭비하지 않아야합니다.

• 셋째, 사용자가 사용 권한이없는 기능을 볼 수 없도록 메뉴를 구성 할 때. 다시 말하지만, 이것은 보안 및 유용성 측면 모두를위한 것입니다. 도움이된다면 사용자가 사용할 수없는 기능으로 사용자를 혼란스럽게하고 싶지는 않습니다.