앱을 안전하게 유지하려면 앱에 액세스할 수 있는 사람과 대상을 제어해야 합니다. 액세스 제어는 인증("허락할 사람")과 승인("무엇"에 액세스할 수 있는지)으로 분류될 수 있습니다.
인증은 나중에 다룰 주제이지만, 사용자 인증에 관해서는 일반적으로 역할 기반 전략이나 리소스 기반 전략을 사용하는 두 가지 방법이 있습니다.
두 부분으로 구성된 이 시리즈에서는 Ruby on Rails 블로그 애플리케이션을 위한 Action Policy gem을 사용하는 방법을 자세히 살펴보겠습니다.
이 부분에서는 액션 정책의 기본 사항을 다루겠습니다.
시작해 보세요!
전제조건
- Ruby(우리는 버전 3.2.2를 사용하고 있습니다)
- 레일(버전 7.0.7 사용)
- Ruby 사용 경험
먼저 리소스 기반 인증을 정의하여 살펴보겠습니다.
자원 기반 승인이란 무엇입니까?
역할 기반 인증은 사전 정의된 사용자 역할에 따라 사용자 권한을 설정하는 데 중점을 두는 반면, 리소스 기반 인증은 애플리케이션 내의 실제 리소스에 대한 규칙을 설정하여 액세스를 적용합니다. 각 리소스는 사용자가 해당 리소스에서 수행할 수 있는 작업을 명시적으로 정의하는 정책과 연결되어 있습니다.
이 문서는 리소스 기반 인증에 중점을 두고 있지만 두 가지 인증 전략의 차이점을 알면 각 전략이 무엇을 할 수 있는지 더 잘 알 수 있다는 의미입니다.
역할 기반 인증을 사용해야 하는 경우
다음과 같은 경우에는 역할 기반 인증을 사용해야 합니다:
- 간단한 애플리케이션 - 간단한 권한 시스템과 더 적은 수의 사용자 역할을 갖춘 앱에서 작업하는 경우 역할 기반 권한 부여 전략이 적합할 수 있습니다.
- 잘 정의된 사용자 그룹 - 앱에 '관리자', '편집자', '작성자' 등과 같이 잘 정의된 사용자 그룹이 있는 경우 사용자 역할 수준에서 액세스 제어를 처리하므로 역할 기반 인증을 사용하세요.
리소스 기반 인증을 사용해야 하는 경우
자원 기반 승인은 다음과 같은 경우에 적합합니다:
- 동적 또는 복잡한 액세스 제어 - 애플리케이션의 인증 요구 사항이 자주 발전하거나 동적 조건에 따라 결정되는 경우 리소스 기반 인증 시스템이 더 나은 선택을 제공합니다.
- 세밀한 제어 - 여러 조건에 따라 리소스에 대한 액세스를 허용하거나 거부해야 하는 경우에 유용합니다(예:사용자가 동적 카테고리 목록을 기반으로 지원 티켓을 제출하는 Rails 헬프데스크 앱). 지원 직원이 카테고리별로 티켓을 할당받는다고 가정하면 리소스 기반 승인이 실제로 빛을 발할 시나리오입니다.
- 객체 지향 제어 - 리소스 기반 인증은 개체 수준에서 발생하므로 리소스 기반 인증 기술을 사용하면 복잡한 개체 지향 규칙을 정의하는 것이 더 쉽습니다.
즉, 역할 기반 인증과 리소스 기반 인증 중 하나를 선택할지는 애플리케이션의 고유한 특성에 따라 달라집니다.
이제 Action Policy gem에 주목해 보겠습니다.
Ruby와 Rails를 위한 액션 정책 Gem
작업 정책은 Ruby 및 Rails 앱을 위한 유연하고 확장 가능하며 성능이 뛰어난 인증 프레임워크입니다. 특히 인증 규칙에 데이터베이스 쿼리가 필요한 경우 다양한 캐싱 전략을 사용하여 속도가 매우 빠릅니다.
이 gem을 리소스 기반 규칙을 구축하는 데 이상적으로 만드는 또 다른 기능은 사용자 정의 기능입니다. 다양한 방법으로 결합할 수 있는 여러 Ruby 클래스와 모듈을 제공합니다. 앱 어디에서나 Rails 컨트롤러를 넘어 세분화된 액세스 제어 규칙을 설정할 수 있습니다.
자세한 내용은 행동 정책 프로젝트 홈페이지를 확인하세요.
이제 오늘 빌드할 Rails 앱을 살펴보겠습니다.
Rails 앱 만들기
앞으로는 사용자가 CRUD(작성, 읽기, 업데이트 및 삭제) 게시물을 작성할 수 있는 Rails 7 블로그 애플리케이션을 참조하겠습니다.
Post에 대한 작업 정책을 점진적으로 정의하겠습니다. 리소스 기반 액세스 제어를 제공하는 모델입니다. 이 액세스 제어 전략을 작동시키기 위해 작업 정책을 사용하는 방법을 배우게 됩니다.
새로운 Rails 애플리케이션을 생성해 보세요:
참고: 예시 앱에는 Pico CSS 스타일을 사용하겠지만 원하는 대로 사용해도 됩니다.
그런 다음 재빨리 Post를 발판으로 삼으세요. 튜토리얼의 나머지 부분에서 사용할 리소스:
이제 rails db:migrate를 사용하여 마이그레이션을 실행하세요. .
사용자 인증 설정
이 문서가 사용자 인증에 관한 것만큼 우리가 다루어야 할 중요한 사항이 있습니다:바로 사용자 인증입니다. 이것이 없으면 나중에 정의하려는 인증 정책은 쓸모가 없습니다. 하지만 처음부터 인증을 작성할 필요는 없습니다. Devise를 사용해 보세요.
장치 설치
Devise gem을 Gemfile에 추가하는 것부터 시작하세요:
그런 다음 설치하고 User을 생성하세요. 모델:
또한 config.action_mailer.default_url_options = { host: 'localhost', port: 3000 }을 추가하는 것을 잊지 마세요. 앱의 개발 구성에 적용됩니다.
다음으로, Post에 대한 다양한 사용자 액세스 시나리오를 테스트하기 위해 몇 가지 기본 사용자 역할을 구현해 보겠습니다. 자원.
기본 사용자 역할 정의
먼저 role를 추가하세요. 사용자 테이블에 대한 열입니다. 마이그레이션을 생성하려면 다음 명령을 실행하세요:
참고: 역할에 정수 데이터 유형을 사용하므로 enum를 사용할 수 있습니다. — 역할을 구현하는 빠르고 쉬운 방법입니다.
이제 rails db:migrate을 사용하여 마이그레이션을 실행하세요. 을 누른 다음 User을 엽니다. 모델을 만들고 편집하세요:
완료되었으면 Action Policy 설치에 초점을 맞춰보겠습니다.
Ruby 및 Rails에 대한 작업 정책 설정
앱의 Gemfile를 엽니다. 그리고 아래 줄을 추가하세요:
그런 다음 bundle install 명령을 실행하세요. 액션 정책을 설치합니다.
다음을 실행하여 설치를 마무리하세요:
이는 ApplicationPolicy라는 기반을 제공해야 합니다. app/policies 아래 클래스 :
액션 정책의 기본 사용법
Action Policy의 핵심 기반은 policy입니다. 클래스, ApplicationPolicy , 모든 정책이 상속될 수 있는 전역 구성을 정의할 수 있습니다. 모든 정책을 app/policies 아래에 배치하는 것이 좋습니다. , 앱의 리소스에 따라 정책을 분리합니다. 예를 들어 Post가 있는 경우 리소스, 해당 정책은 PostPolicy여야 합니다. , CommentPolicy Comment와 함께 제공됩니다. 리소스 등이 있습니다.
작업 정책을 사용할 때 고려해야 할 또 하나의 사항은 규칙 정의가 정책 클래스의 공개 메서드 내에서 발생해야 한다는 것입니다. 비공개 메소드를 사용하면 오류가 발생합니다.
계속해서 이 정보를 사용하여 PostPolicy을 만들어 보겠습니다. 여기서 우리는 다양한 수준의 사용자 액세스를 점진적으로 구축할 것입니다.
첫 번째 정책 만들기
post_policy.rb라는 새 파일을 만듭니다. app/policies 아래 :
여기서는 Post에 대한 간단한 규칙을 정의합니다. 누구나 Post에 액세스할 수 있다고 선언하는 리소스 .
사용자에게 게시물 연결
이 새로운 게시물 정책을 사용하려면 Post를 수정해야 합니다. 생성 시 로그인한 사용자와 연결되도록 이전에 생성한 리소스( user_id 추가) 게시물 테이블의 열):
그런 다음 rails db:migrate를 사용하여 마이그레이션을 실행하세요. .
다음으로 이 변경 사항을 고려하여 게시물 컨트롤러를 수정해야 합니다. 먼저 user_id을 추가해 보겠습니다. 허용된 post_params까지 :
그런 다음 create를 수정하세요. 행동:
다음으로 PostsController을 보호해 보겠습니다. .
컨트롤러에서 권한 부여 구현
PostsController을 수정해야 합니다. 로그인한 사용자에게만 액세스를 허용하는 콜백:
다음으로, 새로운 Post 정책을 사용하여 몇 가지 기본 사용자 액세스 제어를 추가해 보겠습니다.
여기서는 포스트 컨트롤러의 update에 대한 액세스 규칙을 정의합니다. 및 destroy 행동. 게시물 작성자(또는 "작성자" 역할을 가진 사용자)가 게시물을 업데이트할 수 있지만 게시물 작성자만 게시물을 삭제할 수 있도록 지정합니다.
빠른 도움말: 작업 정책은 current_user을 참조할 수 있습니다. Devise에서 제공하고 이를 user에 할당합니다. 정책 내에서.
다음으로, 다음과 같이 게시물 컨트롤러에서 액세스 규칙을 사용해야 합니다:
게시물 컨트롤러에 액세스 규칙이 적용되면 다음 조치는 뷰가 보호되는지 확인하는 것입니다.
인증으로 뷰 보호
아래 스크린샷에서는 이메일이 <user2@example.com>인 사용자입니다. 그리고 "reader" 역할이 로그인되어 있습니다. 보시다시피 이 사용자는 <user@example.com>가 작성한 게시물을 볼 수 있습니다. , 이 게시물의 수정 및 삭제 링크에도 액세스할 수 있습니다. 이는 이상적이지 않습니다. 편집 및 삭제 링크는 게시물 작성자만 사용할 수 있어야 합니다.
우리의 첫 번째 작업은 게시물 작성자가 아닌 사용자의 이러한 링크에 대한 액세스를 제거하는 것입니다. 이 액세스 규칙을 이미 정의했으므로 show에만 적용하면 됩니다. Action Policy의 멋진 allowed_to?을 사용해 보세요. 방법:
이 규칙을 적용하면 이제 게시물의 show을 새로 고칠 수 있습니다. 페이지를 방문하여 우리가 얻는 것을 확인하세요:
액세스 권한이 있었던 동일한 사용자가 이제 게시물을 보는 동안 수행할 수 있는 작업이 제한됩니다.
마무리
두 부분으로 구성된 이 시리즈의 첫 번째 부분에서 우리는 인증 gem 작업 정책에 대한 몇 가지 기본 사항을 배웠습니다.
두 번째이자 마지막 부분에서는 좀 더 고급 사용 사례를 살펴보겠습니다.
즐거운 코딩 되세요!
추신 Ruby Magic 게시물이 보도되는 즉시 읽으려면 Ruby Magic 뉴스레터를 구독하고 단 하나의 게시물도 놓치지 마세요!