ABP 프레임의 매개 변수 유효성 검증 및 권한 검증 상세 설명

매개 변수의 유효성 검증 응용 프로그램의 입력 데이터는 우선 유효성 여부를 검사해야 한다.입력한 데이터는 사용자나 다른 응용 프로그램에 제출될 수 있습니다.웹 응용 프로그램에서 일반적으로 2차례의 데이터 유효성 검사를 실시한다. 클라이언트 검사와 서버 검사를 포함한다.클라이언트의 검사는 주로 사용자에게 좋은 사용자 체험을 제공하는 것이다.우선 클라이언트가 폼 입력의 유효성을 검사하고 클라이언트에게 보여주는 필드 입력이 무효입니다.그러나 서버 측의 검사는 더욱 관건적이고 빠질 수 없는 것이다. (클라이언트 검사만 하고 서버 측 검사는 하지 마라.)
서버 측의 검사는 일반적으로 응용 서비스(층)에 의해 실행되고 응용 서비스(층)의 방법은 데이터의 유효성을 먼저 검사한 다음에 검증된 데이터를 사용한다.ABP의 인프라 시설은 입력 데이터의 유효성을 자동으로 검사하는 방법을 제공한다.
서비스 (레이어) 메서드를 적용하여 데이터 전송 객체(DTO)를 가져옵니다.ABP는 IValidate의 인터페이스를 가지고 있으며 DTO는 이 인터페이스를 실현함으로써 데이터의 유효성을 검증할 수 있다.IInputDto는 IValidate에서 확장되기 때문에 IInputDto 인터페이스를 직접 실현하여 데이터 전송 대상(DTO)에 대한 유효성을 검사할 수 있습니다.
데이터 메모 ABP를 사용하여 데이터 메모의 특성을 제공합니다.만약 우리가 창설 작업의 응용 서비스를 개발하고 입력을 받았다면 다음 예시를 보십시오.

public class CreateTaskInput : IInputDto
{
  public int? AssignedPersonId { get; set; }

  [Required]
  public string Description { get; set; }
}

여기서 Description 속성은 Required로 표시됩니다.AssignedPersonId는 옵션입니다.시스템에서ComponentModel.DataAnnotations 네임스페이스에는 이러한 특성이 많이 있습니다(예: MaxLength, MinLength, Regular Expression 등).
시스템에서ComponentModel.DataAnnotations 네임스페이스에서 Task application 서비스의 구현을 보십시오.
 

public class TaskAppService : ITaskAppService
{
  private readonly ITaskRepository _taskRepository;
  private readonly IPersonRepository _personRepository;

  public TaskAppService(ITaskRepository taskRepository, IPersonRepository personRepository)
  {
    _taskRepository = taskRepository;
    _personRepository = personRepository;
  }

  public void CreateTask(CreateTaskInput input)
  {
    var task = new Task { Description = input.Description };

    if (input.AssignedPersonId.HasValue)
    {
      task.AssignedPerson = _personRepository.Load(input.AssignedPersonId.Value);
    }

    _taskRepository.Insert(task);
  }
}

보시다시피 ABP는 자동으로 데이터의 유효성을 검사하기 때문에 데이터 검증 코드(Description 속성에 대한 검증)를 작성하지 않았습니다.ABP도 입력 데이터가null인지 확인합니다.비어 있으면 AbpValidationException 이상이 발생합니다.그래서 데이터가null값인지 확인하는 코드를 쓸 필요가 없습니다.만약 어떤 속성의 입력 데이터가 무효라면, 그것도 같은 이상을 던질 것이다.
이 메커니즘은 ASP와 비슷하다.NET MVC의 검증 기능, 주의: 이곳의 응용 서비스 클래스는 Controller에서 계승된 것이 아니라 웹 응용에 사용되는 일반 클래스입니다.
사용자 정의 검사 데이터 주석 방식이 당신의 요구를 충족시키지 못하면 ICustomValidate 인터페이스를 실현할 수 있습니다. 다음 예시를 보십시오.

public class CreateTaskInput : IInputDto, ICustomValidate
{
  public int? AssignedPersonId { get; set; }

  public bool SendEmailToAssignedPerson { get; set; }

  [Required]
  public string Description { get; set; }

  public void AddValidationErrors(List results)
  {
    if (SendEmailToAssignedPerson && (!AssignedPersonId.HasValue || AssignedPersonId.Value <= 0))
    {
      results.Add(new ValidationResult("AssignedPersonId must be set if SendEmailToAssignedPerson is true!"));
    }
  }
}

ICustomValidate 인터페이스는 실현 가능한AddValidationErrors 방법을 설명합니다.여기에는 SendEmailToAssignedPerson이라는 속성이 있습니다.이 속성이 사실이면 AssignedPersonId 속성이 유효한지 확인됩니다. 그렇지 않으면 속성이 비어 있을 수 있습니다.만약 검증 오류가 있다면, 우리는 반드시 이 검증 결과를 결과 집합에 추가해야 한다.(ValidationResult를 results에 추가)
기본값을 설정하면 데이터의 유효성을 검사한 후에 DTO 매개 변수를 정리하기 위해 추가 작업을 수행해야 합니다.ABP는 Ishould Normalize 인터페이스를 정의했습니다. 이 인터페이스는 Normalize의 방법을 설명합니다.만약 당신이 이 인터페이스를 실현한다면, 데이터의 유효성을 검사한 후에, Normalize 방법이 호출될 것입니다.DTO에 정렬 방향의 데이터가 필요하다고 가정합니다.만약 이 Sorting 속성이 데이터를 제공하지 않는다면, Normalize에서 Sorting에 부족한 값을 설정할 수 있습니다.

public class GetTasksInput : IInputDto, IShouldNormalize
{
  public string Sorting { get; set; }

  public void Normalize()
  {
    if (string.IsNullOrWhiteSpace(Sorting))
    {
      Sorting = "Name ASC";
    }
  }
}

권한 검증은 거의 모든 기업급 응용 프로그램에서 서로 다른 수준의 권한 검증을 할 수 있다.권한 검증은 사용자가 특정 작업을 허용하는지 확인하는 데 사용됩니다.Abp는 권한 검증을 위한 인프라가 있습니다.
참고: IPermissionChecker 인터페이스 정보
Abp 권한 시스템은 IPermissionChecker를 사용하여 권한 부여를 확인합니다.동시에 당신은 필요에 따라 자신의 방식을 실현할 수 있습니다.module-zero 프로젝트에서 이미 완전하게 실현되었습니다.IPermissionChecker가 실행되지 않으면 NullPermissionChecker는 모든 사람에게 권한을 부여하는 데 사용됩니다.
정의 권한은 검증 권한을 사용하기 전에 모든 작업에 대해 유일한 권한을 정의해야 합니다.Abp의 디자인은 모듈화를 바탕으로 하기 때문에 서로 다른 모듈은 서로 다른 권한을 가질 수 있다.권한을 정의하기 위해서 모듈은 Authorization Provider의 파생 클래스를 만들어야 합니다.My Authorization Provider는 Authorization Provider에서 상속됩니다. 다시 말하면 Authorization Provider가 My Authorization Provider를 파생합니다.예는 다음과 같습니다.

public class MyAuthorizationProvider : AuthorizationProvider
{
  public override void SetPermissions(IPermissionDefinitionContext context)
  {
    var administration = context.CreatePermission("Administration");

    var userManagement = administration.CreateChildPermission("Administration.UserManagement");
    userManagement.CreateChildPermission("Administration.UserManagement.CreateUser");

    var roleManagement = administration.CreateChildPermission("Administration.RoleManagement");
  }
}

IPermissionDefinitionContext는 권한을 얻고 만들 수 있는 방법이 있습니다.
하나의 권한에는 다음과 같은 속성이 있습니다.

Name: 시스템 범위 내의 유일한 이름입니다.그것을 문자열 상수로 정의하는 것은 좋은 주의이다.우리는 "."를서로 다른 등급을 나누지만, 결코 이렇게 하라고 요구하지는 않는다.너는 네가 좋아하는 어떤 이름도 설정할 수 있다.유일한 규칙은 이 이름이 유일해야 한다는 것이다.

DisplayName: UI에 대한 권한을 표시하는 로컬 문자열을 사용합니다

Description: Display Name과 유사..

IsGrantedByDefault: 이 권한은 지정한 것을 표시하지 않는 한 모든 사용자에게 부여되었는지 여부입니다.일반적으로 False(기본값)로 설정됩니다

MultiTenancysides: 임차인 응용 프로그램에 대한 권한은 임차인이나 호스트를 기반으로 할 수 있다.이것은 매거진 표지이기 때문에 권한은 다른 방면에 적용될 수 있다

하나의 권한은 부권한도와 하위 권한이 있을 수 있다.물론 이것은 권한 검사에 영향을 주지 않으며, 단지 UI 층에서 권한 분류에 도움이 될 뿐이다.authorizationprovider를 만든 후에 모듈의 PreIntialize 방법으로 등록해야 합니다.다음과 같습니다.

Configuration.Authorization.Providers.Add()

authorizationprovider는 의존 주입 시스템에 자동으로 등록됩니다.따라서 authorizationprovider는 Repository 같은 모든 의존을 주입하여 다른 자원을 사용하여 권한 정의를 만들 수 있습니다.
권한 확인 1.AbpAuthorize 특성 사용(Using AbpAuthorize attribute)
AbpAuthorize(AbpMvcAuthorize는 MVC Controllers에 대응하고 AbpApiAuthorize는 웹 API Controllers에 대응하는 것)의 특성은 권한을 검사하는 가장 간단하고 자주 사용하는 방법이다.다음과 같은 애플리케이션 서비스 방법을 고려하십시오.

[AbpAuthorize("Administration.UserManagement.CreateUser")]
public void CreateUser(CreateUserInput input)
{
  //A user can not execute this method if he is not granted for "Administration.UserManagement.CreateUser" permission.
}

"Administration.UserManagement.CreateUser"권한을 얻지 못한 사용자는 CreateUser를 호출할 수 없습니다.
AbpAuthorize 기능도 현재 사용자가 로그인했는지 확인합니다(IAbpSession.UserId 사용).따라서 만약 우리가 어떤 방법을 AbpAuthorize 특성으로 성명한다면, 그것은 적어도 사용자가 로그인했는지 검사할 것이다.코드는 다음과 같습니다. [AbpAuthorize]

public void SomeMethod(SomeMethodInput input)
{
  //A user can not execute this method if he did not login.
}

2. AbpAuthorize 속성 설명(AbpAuthorize attribute notes)
Abp는 동적 방법으로 권한 검증을 차단합니다.따라서 AbpAuthorize 특성을 사용하는 방법에는 한계가 있습니다.다음과 같습니다.
개인 (private) 방법에 적용할 수 없습니다. 정적 (static) 방법에 적용할 수 없습니다. 비주입 (non-injected) 클래스에 적용할 수 없습니다. 의존 주입을 사용해야 합니다.그 밖에
AbpAuthorize 기능은 모든 공공 방법에 적용될 수 있습니다. 만약에 이 방법이 인터페이스에서 호출된다면(예를 들어 응용 프로그램 서비스에서 인터페이스를 통해 호출된다면) 방법은 허(virtual) 방법이고, 이 방법이 클래스에서 직접 인용되어 호출된다면(예를 들어 ASP.NET MVC나 웹 API의 컨트롤러)방식은 가상 방법입니다. 만약 이 방법이protected라면.참고: 세 가지 AbpAuthorize 기능이 있습니다.
(1) 응용 프로그램 서비스(application layer)에서 Abp를 사용합니다.Authorization.AbpAuthorize; (2) MVC 컨트롤러(web layer)에서 Abp를 사용합니다.Web.Mvc.Authorization.AbpMvcAuthorize; (3) ASP에 있습니다.NET 웹 API, Abp를 사용합니다.WebApi.Authorization.AbpApiAuthorize. 이 세 종류는 서로 다른 곳에서 계승한다.
VC에서는 MVC 자체의 Authorize 클래스를 상속합니다.웹 API에서는 웹 API의 Authorize 클래스를 상속합니다.따라서 MVC 및 웹 API에 상속되는 것이 좋습니다.그러나 응용 프로그램 층에서는 완전히 Abp 자체로 확장자가 없는 종류를 실현한다.3. IPermissionChecker 사용
AbpAuthorize는 대부분의 경우에 적용되지만, 어떤 경우에는 방법체에서 권한 검증을 해야 합니다.IPermissionChecker 객체를 주입하고 사용할 수 있습니다.아래 코드와 같이

 public void CreateUser(CreateOrUpdateUserInput input)
{
  if (!PermissionChecker.IsGranted("Administration.UserManagement.CreateUser"))
  {
    throw new AbpAuthorizationException("You are not authorized to create user!");
  }

  //A user can not reach this point if he is not granted for "Administration.UserManagement.CreateUser" permission.
}

물론, 당신은 어떤 논리를 쓸 수 있습니다. 왜냐하면 IsGranted 방법은true나false로 간단하게 되돌아오기 때문입니다. (이동 버전도 있습니다.)간단하게 권한을 검사하고 위의 코드와 같은 이상을 던지면 Authorize 방법을 사용할 수 있습니다.

public void CreateUser(CreateOrUpdateUserInput input)
{
  PermissionChecker.Authorize("Administration.UserManagement.CreateUser");

  //A user can not reach this point if he is not granted for "Administration.UserManagement.CreateUser" permission.
}

권한 검증은 일반적으로 응용 프로그램 층과 이루어지기 때문에 응용 프로그램 서비스 기본 클래스는 PermissionChecker 속성을 주입하고 정의합니다.따라서 권한 검사자는 주입을 표시하지 않고 응용 프로그램 서비스 클래스에서 사용할 수 있습니다.