Rails権限・ロールまわり調査

概要

Railsでのロール管理・アクセス権限管理のやり口について調べたときのメモ

アクセス権限チェック(認可)

・cancancan
・pundit
・banken

認可について

設定ファイルがシンプルそうでrubyで書けるpunditかbankenがやりやすそう。
普及具合で言えばpundit。ただbankenのスライドを見ると、「作成者がcancancanとpunditの不満点をクリアしたもの」、ということもありbankenが良さそうに見える。

role設定(権限管理)

・rolify

それぞれのgemの概要は後述。

それぞれのgemの

※以下スライドはcancancan、pundit、bankenの違いがわかりやすい。
https://speakerdeck.com/kyuden/rails-authorization

※以下はcancancanとpuditの比較参考
https://www.icare.jpn.com/dev_cat/pundit%E3%81%A8cancancan%E3%81%AE%E6%AF%94%E8%BC%83/

role(権限)の設定については

１.roleは１ユーザーに一つだけなら、usersテーブルにenumで持たせるで事足りそう。(rolifyでもOK)
2. 複数設定可能にしたいならrolifyを使うのが簡単そう。
3. roleのテーブルに役職和名など付加情報も持たせるなら、独自でroleのマスタと関連付けテーブルを作成するか。

認証は、sorceryの方がカスタマイズしやすいという記述をみるので、汎用テンプレートとしてはsorceryの方が無難かなと。

なので
認証：sorcery
認可：bunken (or pundit)
権限付与：rolifyか独自か

というイメージが汎用的そう。

以下のgunosyブログの構成と似た感じ、というか引きずられている

　各geｍの概要

cancancan(DL数:22,394,057)

出来ること
・一つのAbilityクラスファイルに、権限毎にモデル + アクションで許可条件を定義できる。

基本的な使い方
・Abilityクラスを作成して、独自DSLで記述していく。
・「can/cannot アクション名、モデル、条件」というのが基本的な書き方の様子。

  def initialize(user)
    can :read, Post, public: true

    if user.present?  
      can :read, Post, user_id: user.id
      
      if user.admin?  
        can :read, Post
      end
    end
  end

デメリット
・独自記法の学習コストあり
・基本一つのAbilityファイルに権限*各モデルへのcan/canontを書いていくので肥大化しやすい。条件分岐も多くなると見通しが悪くなりそう。

参考URL
https://qiita.com/senou/items/e28ff548e93ad0eeed3f
https://qiita.com/naoki85/items/266c8d7ab469cc6ab1fe
https://qiita.com/umanoda/items/679419ce30d1996628ed
https://happy-teeth.hatenablog.com/entry/2018/12/09/002905

pundit(DL数:20,682,033)

https://github.com/varvet/pundit
出来ること
・Model毎にPolicyクラスを作成しAction名に対する認可条件を定義できる
・rubyで書ける。
・※一つのモデルに対して、一つのポリシーしか紐付けることは出来ない。apiと通常の画面で同じモデルを参照する場合、一つのpolicyファイルに記載することになる。

基本的な使い方
・モデル毎にPolicyファイルを作成する。
・Policyファイルの中で条件判定用の関数を書く。
・利用する時はコントローラー等から、authorizeを実行して判定結果を受取って制御する。

デメリット
・Model + アクション名に対して一つしか定義をかけない。画面用コントローラーとAPIコントローラで制御を別にするなら、アクション名が重複するとだめらしい。

参考URL
https://qiita.com/senou/items/e28ff548e93ad0eeed3f

banken(DL数:285,710)

出来ること
punditにおける「モデルとpolicyが1対1の必要がある」という制約をはずして、コントローラー毎にActionに対する認可条件を記載できるようにしている。

基本的な使い方
・コントローラー毎にloyaltyファイルを生成する。
・アクション名毎に認可条件を記載して、コントローラ側でauthorizeを実行して判断する。

デメリット
・pundit, cancancanに比べて利用数が少ない。
・punditとくらべると、scope機能なし

参考URL
スライドシェア
https://speakerdeck.com/kyuden/rails-authorization
https://github.com/kyuden/banken
日本語ドキュメント

Rolify(DL数:6,307,168) (権限設定gem)

出来ること
Usersなど認証に使っているモデルにRoleを関連付けることができる。role用のモデルとメソッドが生成される。前段の認可の仕組みでは無くて、権限付与のためのgem。
Roleは１ユーザーに複数の設定も可能。

基本的な使い方
・ユーザー作成時等に、add_role()で特定のロールをセットしてあげる。
・ユーザーが特定の権限を持っているかどうかは、user.has_role?()で取得できるのでroleをそこで確認。その結果のアクセス制御はcancancanやpunditで設定する。

参考URL
https://qiita.com/tatsurou313/items/0f632887d049e9503e3b
https://github.com/RolifyCommunity/rolify

他

認証にclearchnceとauthlogicというものもあるが、割愛