DeclarativePolicy 프레임워크

GitLab의 DeclarativePolicy 프레임워크를 사용하여 권한 규칙을 정의하고 성능 최적화 방법을 설명합니다.

DeclarativePolicy 프레임워크는 정책 검사 성능을 향상시키고 EE 확장을 용이하게 하기 위해 설계되었습니다. app/policies 의 DSL 코드는 Ability.allowed? 가 특정 액션이 subject에 허용되는지 확인하는 데 사용됩니다. 사용되는 정책은 subject의 클래스명을 기반으로 결정됩니다. 예를 들어 Ability.allowed?(user, :some_ability, project) 는 ProjectPolicy 를 생성하고 해당 정책에 대한 권한을 확인합니다. Ruby gem 소스는 declarative-policy GitLab 프로젝트에서 확인할 수 있습니다. 명명 규칙에 대한 정보는 권한 규칙 을 참조하세요. 권한 규칙 관리 # 권한은 conditions 와 rules 의 두 부분으로 나뉩니다. Conditions는 데이터베이스와 환경에 접근할 수 있는 불리언 표현식이며, rules는 특정 능력을 활성화하거나 차단하는 표현식과 다른 rules의 정적으로 구성된 조합입니다. 능력이 허용되려면 적어도 하나의 rule에 의해 활성화되고, 어떤 rule에 의해서도 차단되어서는 안 됩니다. Conditions # Conditions는 condition 메서드로 정의되며, 이름과 블록이 주어집니다. 블록은 정책 객체의 컨텍스트에서 실행됩니다. 따라서 @user 와 @subject 에 접근하거나 정책에 정의된 모든 메서드를 호출할 수 있습니다. @user 는 nil일 수 있지만(익명의 경우), @subject 는 subject 클래스의 실제 인스턴스임이 보장됩니다. class FooPolicy < BasePolicy condition(:is_public) do # @subject guaranteed to be an instance of Foo @subject.public? end # instance methods can be called from the condition as well condition(:thing) { check_thing } def check_thing # ... end end condition을 정의하면 해당 condition이 충족되는지 확인하는 predicate 메서드가 정책에 정의됩니다. 위의 예에서 FooPolicy 의 인스턴스는 #is_public? 과 #thing? 에도 응답합니다. Conditions는 scope에 따라 캐시됩니다. Scope와 순서는 뒤에서 다룹니다. Rules # rule 은 conditions와 다른 rules의 논리적 조합으로, 특정 능력을 활성화하거나 차단하도록 구성됩니다. rule 구성은 정적입니다. rule의 로직은 데이터베이스에 접근하거나 @user 또는 @subject 에 대해 알 수 없습니다. 이를 통해 condition 수준에서만 캐싱할 수 있습니다. Rules는 DSL 구성의 블록을 받아 #enable 또는 #prevent 에 응답하는 객체를 반환하는 rule 메서드를 통해 지정됩니다. class FooPolicy < Bas