Ruby on Rails でアクション ポリシーをマスターする:安全な認可のための実践ガイド

アプリを安全に保つには、アプリにアクセスできるユーザーと内容を制御する必要があります。アクセス制御は、「誰に」アクセスを許可する認証と、「何に」アクセスできる認可に分類できます。

認証については別の日に取り上げますが、ユーザーの承認に関しては、通常、ロールベースの戦略を使用するか、リソースベースの戦略を使用するかの 2 つの方法があります。

この 2 部構成のシリーズでは、Ruby on Rails ブログ アプリケーションでの Action Policy gem の使用について詳しく説明します。

このパートでは、アクション ポリシーの基本について説明します。

始めましょう!

前提条件

• Ruby (バージョン 3.2.2 を使用しています)
• Rails (バージョン 7.0.7 を使用)
• Ruby の使用経験

まずリソースベースの認可を定義することから始めましょう。

リソースベースの認可とは何ですか?

ロールベースの承認では、事前定義されたユーザー ロールに従ってユーザー権限を設定することに重点が置かれていますが、リソース ベースの承認では、アプリケーション内の実際のリソースにルールを設定することによってアクセスが強制されます。各リソースは、ユーザーがそのリソースに対して実行できる内容を明示的に定義するポリシーに関連付けられています。

この記事はリソースベースの認可に焦点を当てていますが、2 つの認可戦略の違いを理解することは、それぞれが何ができるかをよりよく理解できることを意味します。

ロールベースの認証を使用する場合

以下の場合には、ロールベースの認可を使用する必要があります。

• 簡単なアプリケーション - 単純な権限システムでユーザーの役割が少ないアプリに取り組んでいる場合は、役割ベースの認可戦略がうまく機能する可能性があります。
• 明確に定義されたユーザー グループ - アプリに「管理者」、「編集者」、「ライター」などの明確に定義されたユーザー グループがある場合は、ユーザー ロール レベルでアクセス制御を処理するため、ロールベースの承認を使用します。

リソースベースの認証を使用する場合

リソースベースの認可は次の場合に最適です。

• 動的または複雑なアクセス制御 - アプリケーションの認可ニーズが頻繁に変化する場合、または動的な条件によって決定される場合には、リソースベースの認可システムがより良い選択となります。
• きめ細かい制御 - 複数の条件に基づいてリソースへのアクセスを許可または拒否する必要がある場合に役立ちます (たとえば、ユーザーが動的カテゴリのリストに基づいてサポート チケットを送信する Rails ヘルプデスク アプリ)。サポート スタッフにカテゴリごとにチケットが割り当てられていると仮定すると、これはリソースベースの承認が真価を発揮するシナリオです。
• オブジェクト指向制御 - リソースベースの認可はオブジェクト レベルで行われるため、リソースベースの認可テクニックを使用すると、複雑なオブジェクト指向ルールの定義が簡単になります。

ただし、ロールベースの認可とリソースベースの認可のどちらを選択するかは、アプリケーションの固有の特性によって異なります。

ここで、Action Policy gem に注目してみましょう。

Ruby と Rails のアクション ポリシー Gem

Action Policy は、Ruby および Rails アプリ向けの柔軟で拡張性があり、パフォーマンスに優れた認可フレームワークです。すぐに使用できる複数のキャッシュ戦略を使用するため、特に認可ルールでデータベース クエリが必要な場合、非常に高速になります。

この gem をリソースベースのルールの構築に最適にするもう 1 つの特徴は、カスタマイズできることです。さまざまな方法で組み合わせることができる、いくつかの 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 を開きます。 モデルを作成して編集します。

それが完了したら、アクション ポリシーのインストールに焦点を移しましょう。

Ruby と Rails のアクション ポリシーの設定

アプリの Gemfile を開きます そして、以下の行を追加します。

次に、コマンド bundle install を実行します。 アクション ポリシーをインストールします。

以下を実行してインストールを完了します。

これにより、ベースとなる ApplicationPolicy が得られるはずです。 app/policies のクラス :

アクション ポリシーの基本的な使用方法

アクション ポリシーの中核基盤は policy です。 クラス、ApplicationPolicy ここで、すべてのポリシーが継承できるグローバル構成を定義できます。すべてのポリシーを app/policies の下に配置することをお勧めします。 、アプリ内のリソースに応じてポリシーを分離します。たとえば、Post がある場合、 リソースの場合、対応するポリシーは PostPolicy である必要があります。 、CommentPolicy Comment が付きます。 リソースなど。

アクション ポリシーを使用するときに考慮すべきもう 1 つの点は、ルール定義はポリシー クラスのパブリック メソッド内で行われる必要があるということです。プライベート メソッドを使用するとエラーが発生します。

次に、この情報を使用して PostPolicy を作成しましょう。 ここで、さまざまなレベルのユーザー アクセスを段階的に構築していきます。

最初のポリシーの作成

post_policy.rb という名前の新しいファイルを作成します。 app/policies の下 :

ここでは、Post に簡単なルールを定義します。 誰もが Post にアクセスできることを宣言するリソース .

投稿をユーザーに関連付ける

この新しい投稿ポリシーを使用するには、Post を変更する必要があります。 作成時にログイン ユーザーに関連付けられるように、以前に生成したリソース (user_id を追加することで) 列をpostsテーブルに追加):

次に、rails db:migrate を使用して移行を実行します。 .

次に、この変更を考慮して投稿コントローラーを変更する必要があります。まず、user_id を追加しましょう 許可される post_params まで :

次に、create を変更します。 アクション:

次に、PostsController を確保しましょう。 .

コントローラでの認可の実装

PostsController を変更する必要があります。 ログインしているユーザーのみにアクセスを許可するコールバックを使用します:

次に、新しい Post ポリシーを使用して、基本的なユーザー アクセス制御を追加しましょう。

ここでは、投稿コントローラーの update にアクセス ルールを定義します。 と destroy アクション。投稿の作成者 (または「作成者」ロールを持つユーザー) が投稿を更新できるが、投稿を削除できるのは投稿の作成者のみであることを指定します。

簡単なヒント: アクション ポリシーは current_user を参照できます。 Devise によって提供され、それを user に割り当てます。 ポリシー内で。

次に、投稿コントローラーでアクセス ルールを次のように使用する必要があります。

アクセス ルールが投稿コントローラーに適用されたので、次のアクションはビューが保護されていることを確認することです。

承認によるビューの保護

以下のスクリーンショットでは、電子メール <user2@example.com> を持つユーザーが ご覧のとおり、このユーザーは <user@example.com> によって作成された投稿を表示できます。 、そしてこの投稿の編集リンクと削除リンクにもアクセスできます。これは理想的ではありません。編集リンクと削除リンクは投稿の作成者のみが利用できるようにする必要があります。

最初のタスクは、投稿の作成者ではないユーザーのこれらのリンクへのアクセスを削除することです。このアクセス ルールはすでに定義されているため、それを show に適用するだけで済みます。 アクション ポリシーの気の利いた allowed_to? を使用して表示します。 メソッド:

このルールを適用すると、投稿の show を更新できるようになります。 ページにアクセスして、何が得られるかを確認してください:

アクセス権を持っていた同じユーザーは、投稿のビュー上でできることが制限されるようになりました。

まとめ

この 2 部構成シリーズの最初の部分では、認可 gem アクション ポリシーに関する基本のいくつかを学習しました。

最後の 2 番目のパートでは、より高度な使用例をいくつか検討します。

コーディングを楽しんでください!

追記Ruby Magic の投稿を報道後すぐに読みたい場合は、Ruby Magic ニュースレターを購読して、投稿を 1 つも見逃さないようにしてください。