implement-authorization

認可の実装

クイックリファレンス

Gem	パターン	最適な用途
Pundit	明示的なポリシークラス	リソースごとの複雑なルール
CanCanCan	集約された Ability クラス	シンプルなロールベースの権限

基本的なプロセス

実装ワークフロー

1. 既存の認可を確認する — インストール済みのポリシーフレームワークを再利用します。新しいフレームワークが必要で、プロジェクトの規約でも許可されている場合に限り、pundit または cancancan を追加します
2. 必要な場合にのみ基盤を生成する — 対応するフレームワークが存在せず、プロジェクトでジェネレーターの使用が許可されている場合に限り、Gem のインストーラー（rails g pundit:install または rails g cancan:ability）を実行します。それ以外の場合は、検出したフレームワークを使い、ジェネレーターを実行せずに進めます
3. ポリシー／権限を定義する — ポリシークラス（Pundit）を作成するか、Ability クラス（CanCanCan）に定義します。必ずポリシーオブジェクトを使用し、コントローラーに認可ロジックを直接記述しないでください
4. コントローラーで認可する — 各アクションで authorize @record（Pundit）または authorize! :action, @record（CanCanCan）を呼び出します
5. 認可を検証する — ブラウザーまたはコンソールで認可されていないアクションを試し、想定どおり Pundit::NotAuthorizedError または CanCan::AccessDenied が発生することを確認します。未保存のレコードではなく、保存済みのレコード（例：User.create!）を使用します
6. クエリをスコープする — index アクションでは policy_scope(Model) または accessible_by(current_ability) を使用します
7. すべてのロールをテストする — admin、owner、guest を対象にしたポリシーのスペックとリクエストスペックを記述します。特定の権限を確認し、存在チェックだけで済ませないでください

パターン

Pundit

class PostPolicy < ApplicationPolicy
  def update?
    user.admin? || record.user_id == user.id
  end
end

CanCanCan

class Ability
  include CanCan::Ability

  def initialize(user)
    can :update, Post, user_id: user.id
    can :manage, :all if user.admin?
  end
end

トラブルシューティング

エラー	考えられる原因	修正方法
Pundit::NotDefinedError	レコードに対応するポリシークラスが見つからない	ApplicationPolicy を継承する app/policies/model_policy.rb を作成します
Pundit::AuthorizationNotPerformedError	コントローラーのアクションで authorize が呼び出されていない	アクションに authorize @record を追加するか、呼び出し漏れを検出するために after_action :verify_authorized を追加します
CanCan::AccessDenied が予期せず発生する	Ability のルールが現在のユーザー／ロールに一致していない	コンソールで current_ability.can?(:action, @record) を調べ、ルールの評価をデバッグします

テスト

ポリシーのスペックとリクエストスペックの両方で、すべてのロール（admin、owner、guest）を網羅します。

最小限の Pundit ポリシースペック

RSpec.describe PostPolicy do
  subject { described_class.new(user, post) }

  let(:post) { create(:post, user: owner) }
  let(:owner) { create(:user) }

  context 'as admin' do
    let(:user) { create(:user, :admin) }
    it { is_expected.to permit_action(:update) }
  end

  context 'as owner' do
    let(:user) { owner }
    it { is_expected.to permit_action(:update) }
  end

  context 'as guest' do
    let(:user) { create(:user) }
    it { is_expected.not_to permit_action(:update) }
  end
end

出力スタイル

認可を実装またはレビューする場合、出力の answer.md には次の内容を含める必要があります。

1. 拒否されたアクションの手動検証 — 実際の Rails コンソール出力を記載する専用セクション、または認可されていないアクションを試した際に発生する認可例外を示す、未実行であることの明示的なステータスを記載します。必ず保存済みのレコード（User.create!、Post.create!）を使用し、未保存のレコードは使用しないでください。
2. HTTP とポリシーの検証 — アクセス拒否時に想定される HTTP レスポンスコード（例：403 Forbidden または 302 Found）を含む、具体的な curl リクエストまたはコントローラーテストのコマンドを記載します。
3. 言語 — 明示的に別の言語が指定されていない限り、英語を使用します。

Pundit と CanCanCan のコンソール出力テンプレートを含む、書式の完全な例については、references/output-style.md を参照してください。

統合

スキル	連携するタイミング
write-tests	認可テストを実装する場合。

拡張リソース（段階的な開示）

該当する内容が必要な場合にのみ、これらのファイルを読み込みます。

• EXAMPLES.md — インラインの例より詳しい Pundit または CanCanCan の実装例が必要な場合に使用します
• references/workflow.md — 認可実装の手順を示すワークフロー図が必要な場合に使用します
• references/output-style.md — コンソール検証出力の書式テンプレート一式が必要な場合に使用します