Pundit을 통한 Rails 인증

Pundit은 매우 간단한 API를 통해 인증을 처리하는 Ruby gem입니다.

인증은 인증과 다르다는 점을 기억하십시오. 인증은 본인이 본인임을 확인하고 인증은 작업을 수행 할 수있는 권한이 있는지 확인하는 것입니다.

Pundit은 인증 캠프 내에 있습니다. Devise와 같은 다른 인증 시스템을 사용하여 인증을 처리합니다.

Pundit과 함께 일하는 방법

1 단계 : 당신은 생성 Policy- 그것이다는 기록의 특정 유형에 대한 액세스 권한을 부여 다루고 해당 클래스 BlogPotato또는 User.

2 단계 : 내장 authorize함수를 호출하여 액세스 권한을 부여하려는 항목을 전달합니다.

3 단계 : Pundit은 적절한 Policy클래스 를 찾고 Policy인증하는 메서드의 이름과 일치하는 메서드를 호출합니다 . true를 반환하면 작업을 수행 할 권한이있는 것입니다. 그렇지 않으면 예외가 발생합니다.

매우 간단합니다. 특정 모델에 대한 논리는 자체 정책 클래스로 캡슐화되어 일을 깔끔하게 유지하는 데 좋습니다. 경쟁 권한 라이브러리 cancancan은 복잡한 권한이 손에 닿지 않는 문제가있었습니다.

사소한 조정 필요

더 복잡한 인증 사용 사례를 지원하기 위해 Pundit의 간단한 규칙을 수정해야하는 경우가 있습니다.

정책 내에서 더 많은 정보에 액세스

기본적으로 학자는 권한 부여 컨텍스트에 두 개체를 제공하는 다음 User과이 Record권한을. 이것은 당신이 같은 시스템에 시스템 전체의 역할이 있으면 충분 Admin하거나 Moderator,하지만 당신은 좀 더 구체적인 상황에 권한을 부여해야 할 때 충분하지 않습니다.

의 개념을 지원하는 시스템이 Organization있고 해당 조직 내에서 다른 역할을 지원 해야한다고 가정 해 보겠습니다 . 시스템 전체의 권한 부여는 문제를 해결하지 못합니다. 두 조직의 관리자가 아닌 경우 Organization Potato의 관리자가 Organization Orange에 작업을 수행하는 것을 원하지 않습니다. 이 경우 권한을 부여하면 3 개 항목에 액세스 할 필요 UserRecord에서, 사용자의 역할 정보를 Organization. 이상적인 경우는 레코드가 속한 조직에 액세스하는 것이지만 더 어렵게 만들고 레코드 나 사용자를 통해 액세스 할 수 없다고 가정 해 보겠습니다.

Pundit은 추가적인 맥락을 제공 할 수있는 기회를 제공합니다. 라는 함수를 정의 pundit_user하면 user. 해당 함수에서 권한 부여 컨텍스트가있는 객체를 반환하면 해당 컨텍스트를 정책에서 사용할 수 있습니다.

application_controller.rb

class ApplicationController < ActionController::Base include Pundit
 def pundit_user AuthorizationContext.new(current_user, current_organization) endend

authorization_context.rb

class AuthorizationContext attr_reader :user, :organization
 def initialize(user, organization) @user = user @organization = organization endend

application_policy.rb

class ApplicationPolicy attr_reader :request_organization, :user, :record
 def initialize(authorization_context, record) @user = authorization_context.user @organization = authorization_context.organization @record = record end
 def index? # Your policy has access to @user, @organization, and @record. endend

이제 정책에서 세 가지 정보에 모두 액세스 할 수 있습니다. 필요한 경우 추가 정보에 액세스하는 방법을 확인할 수 있습니다.

규칙을 무시하고 사용할 정책 지정

Pundit은 이름 지정 규칙을 사용하여 인증하려는 항목을 올바른 정책과 일치시킵니다. 대부분의 경우이 방법은 잘 작동하지만 특정 경우에는 연결된 모델이없는 일반 대시 보드 작업을 승인하려는 경우와 같이이 규칙을 재정의해야 할 수 있습니다. 기호를 전달하여 권한 부여에 사용할 작업 또는 정책을 지정할 수 있습니다.

#Below will call DashboardPolicy#bake_potato?authorize(:dashboard, :bake_potato?)

이름이 다른 모델이 policy_class있는 경우 모델 자체 내에서 함수를 재정의 할 수도 있습니다 .

class DashboardForAdmins def self.policy_class DashboardPolicy # This forces Pundit to use Dashboard Policy instead of looking # for DashboardForAdminsPolicy endend

테스팅

인증은 자동화 된 테스트 도구 모음을 사용하는 것이 좋습니다. 그것들을 잘못 설정하는 것은 치명적일 수 있으며, 제 생각에는 수동으로 테스트하는 것이 가장 지루한 작업 중 하나입니다. 단일 명령을 실행할 수 있고 권한 부여 비즈니스 규칙을 실수로 변경하지 않았다는 것을 아는 것은 좋은 느낌입니다.

Pundit은 테스트 승인을 매우 간단하게 만듭니다.

def test_user_cant_destroy? assert_raises Pundit::NotAuthorizedError do authorize @record, :destroy? endend
def test_user_can_show? authorize @record, :show?end

전반적으로 나는 Pundit을 좋아합니다. 잠시 동안 만 사용해 왔지만 이미 cancancan보다 선호합니다. 유지 관리와 테스트가 더 쉬워졌습니다.

이 이야기가 도움이 되었습니까? 박수 를 보내 주세요 !

도움이되지 않았다면 댓글로 이유를 알려주세요 !