GraphQL 인가

GitLab GraphQL API에서 타입, 리졸버, 필드에 인가를 적용하는 방법과 DeclarativePolicy 기반 권한 검사 패턴을 설명합니다.

인가는 다음 위치에 적용할 수 있습니다: 타입: 객체( ::Types::BaseObject 를 상속하는 모든 클래스) Enum( ::Types::BaseEnum 을 상속하는 모든 클래스) 리졸버: 필드 리졸버( ::Types::BaseResolver 를 상속하는 모든 클래스) 뮤테이션( ::Types::BaseMutation 을 상속하는 모든 클래스) 필드( field DSL 메서드를 사용하여 선언된 모든 필드) 추상 타입(인터페이스 및 유니온)에는 인가를 지정할 수 없습니다. 추상 타입은 멤버 타입에 인가를 위임합니다. 정수와 같은 기본 내장 스칼라 타입에는 인가가 없습니다. 저희 인가 시스템은 애플리케이션 전반에 걸쳐 사용되는 동일한 DeclarativePolicy 시스템을 사용합니다. 단일 값(예: Query.project )의 경우, 현재 인증된 사용자가 인가 검사를 통과하지 못하면 해당 필드는 null 로 반환됩니다. 컬렉션(예: Project.issues )의 경우, 사용자의 인가 검사에 실패한 객체를 제외하도록 컬렉션이 필터링됩니다. 이 필터링 과정( redaction 이라고도 함)은 페이지네이션 이후에 발생하므로, 삭제된 객체가 제거됨에 따라 일부 페이지의 크기가 요청한 페이지 크기보다 작을 수 있습니다. 뮤테이션에서 리소스 인가하기 도 참고하세요. 인가에 의존하여 레코드를 필터링하는 방식보다, 기존 파인더(finder)를 사용하여 현재 인증된 사용자가 볼 수 있는 데이터만 먼저 로드하는 것이 모범 사례입니다. 이렇게 하면 데이터베이스 쿼리와 로드된 레코드에 대한 불필요한 인가 검사를 최소화할 수 있습니다. 또한 기밀 리소스의 존재를 노출할 수 있는 짧은 페이지와 같은 상황도 방지할 수 있습니다. 여기서 설명한 모든 인가 체계의 예시는 authorization_spec.rb 를 참고하세요. 타입 인가 # authorize 메서드에 ability를 전달하여 타입을 인가합니다. 동일한 타입을 사용하는 모든 필드는 현재 인증된 사용자가 필요한 ability를 가지고 있는지 확인하여 인가됩니다. 예를 들어, 다음 인가는 현재 인증된 사용자가 read_project ability를 가진 프로젝트만 볼 수 있도록 보장합니다( Types::ProjectType 을 사용하는 필드에서 프로젝트가 반환되는 한): module Types class ProjectType < BaseObject authorize :read_project end end 여러 ability에 대해 인가할 수도 있으며, 이 경우 모든 ability 검사를 통과해야 합니다. 예를 들어, 다음 인가는 현재 인증된 사용자가 프로젝트를 보기 위해 read_project 와 another_ability ability를 모두 가져야 함을 보장합니다: module Types class ProjectType < BaseObject authorize [:read_project, :another_ability] end end 리졸버 인가 # 리졸버는 자체 인가를 가질