TheRole 3. Ruby on Railsの承認

TheRole -RoRサイトでのロール配布の組織のためのgem（ コントロールパネル付き ）

tl; dr

Webアプリケーションで権利の差別化を提供する別の（1001st）方法。 このソリューションの概念は、PHPで長い間実装され、後にrubyで書き直されました。 実装が単純であるため、説明したアプローチはRails 、 LaravelなどのMVCフレームワークに適用できます。



本文では、アプリケーションへのソリューションの技術的統合だけでなく、提案された実装の理由も詳細に開示しようとしました。



2015年には、Ruby on Railsのユーザー権利を配布するための別のgemを書くことを敢えてできるのは、狂人だけかもしれません。 結局のところ、誰もが長い間 CanCan 、 Pundit、または最終的にAcl9を使用しています。 ただし、すべてがそれほど単純ではありません。 まず、自分を正当化する理由がいくつかあります。

• 今日お話しする決定は、ルビーになるずっと前に現れました。 最初の作業コンセプトは、2006年にPHPで学校のサイト用に作成されました
• 私にとって幸運なことに、私は他のアプローチを知らなかったので、想像力を自由に飛ばすことができました。 他の人のアイデアを繰り返していると非難されることはまずありませんし、私の発明を実践することは常に興味深いです
• 私にとって、このようなプロジェクトは、オンライントレーニングのために受講する人々と協力するためのプラットフォームです。 そして、それでも、TheRoleは鉄道の世界に小さなビーバーをもたらします
• どんなgemの開発でもフィードバックが得られ、それにより少し良くなることができます（私はIvanovoに長く住んでいました）
• TheRoleで実装されたアプローチは、PHP、JS、Pythonで簡単、簡単、迅速に繰り返すことができます。 突然、MVCの認証問題を解決するこのオプションが好きになり、 Laravelでそれを繰り返すことになります。 知る方法？！

第二に、以下では、RoRプロジェクトで役割分担を整理する方法を詳細に説明するだけでなく、このソリューションの理由と歴史についても触れます。 解決しようとしていたタスク、gemの機能、適用性の限界、ユースケースについて（そして誇りを持ってではなく）、私はあなたの勤勉で才能のあるオンライン学生仲間の1人を紹介します。非常に長い間。

TheRoleとは何ですか？

ツリーで考えを広める前に、プロジェクトでTheRoleを使用する方法を詳細に説明するために、このツールのビジョンを定式化しようとします。



TheRoleは、RoRアプリケーション用の役割ベースの境界設定システムです。

1. プロジェクトのアクセス制御に事前定義されたパスを提供します
2. ほとんどの場合、追加のプログラミングは必要ありません
3. コントローラーに統合してアクションへのアクセスを制限する簡潔な方法があります
4. 「契約vs. 構成»
5. アクセスリストを管理するためのGUIがあります
6. 実装の単純さ、少量のコード、およびruby / rails / databaseのすべての主要な組み合わせのテストによる適切なカバレッジにより、十分な信頼性と十分なサポート

間違いなく、この決定は万能薬ではなく、多くのプラス面とマイナス面があります。 私の意見では、何が重要であるかについて話をしようとします。この問題に関するあなたの意見を知りたいと思います。

ちょっとした歴史

私がまだ学生だった2006-2007年、私は最初に商用プロジェクトでPHPを使用しなければなりませんでした。 率直に言って、私が見たものは非常にショックを受けたため、PHPコードを整理する方法を模索し始めました。 短い検索で、MVCアーキテクチャに至りました。 その時点でPHPで許容できる解決策を見つけられなかったため、プログラミングへの情熱と自由時間の利用可能性により、自分のMVCフレームワークをPHPで自己完結的に書くことになりました。



私は、教師として働いていた学校のウェブサイトで、新しく造られたMVCバイクの実行に成功しました。 すぐに、サイト上のユーザーの役割の分布について疑問に思いました。 要するに、希望する解決策が見つかりませんでした。 また、 コントローラー/アクションを使用したMVCの自作の実装と、ロールベースのアクセスポリシーを管理するための管理パネルを作成したいという願望と相まって、別のPHPバイクを作成するようになりました。



2008年、私はRuby on Railsの trapに陥り、私のPHP実験はすべて過去のものになりました。 しかし、Rubyコードで私の決定の1つを繰り返したいという欲求に悩まされました。 2011年に亡くなったPHPの概念をルビーに実装し始めたとき、同僚は理由を挙げて微笑んだ。 当時のCanCanは、事実上の生産ソリューションでした。 そして、車輪を再発明する必要はまったくありませんでした。 しかし、私は夢をあきらめることに慣れていません。 それで、私はこの宝石を書くのにゆったりとした仕事を始めました。

なぜTheRoleが作成されるのですか？

私が追求した主な目標は、グラフィカルインターフェイスを使用してアクセス権を区別するためのソリューションを作成することでした。



問題を解決するための「プログラマーのアプローチ」に満足していません。アクセス制御のために、まず何か（ Abilityクラスなど）をプログラムする必要があり、次にアクセスポリシー（既存の機能するシステム）を変更する必要がある場合、何かを再プログラミングするプログラマーを招待する必要があります（読み取り、間違いを犯す）、サーバーを再コーディングします。



問題を解決するための「ユーザーアプローチ」に満足しています。サイト管理者が最小限の準備で、提供されたインターフェイスを介して一部のサイト機能へのアクセスポリシーを個別に変更できます。 （私はここでエラーを起こす確率が少なくないことを否定しませんが、少なくともエラーの結果はプログラマーの肩にはありません）

どのアクセス基準が存在しますか？

さまざまなシステムでのアクセス制御の原則を調査することで、何らかの方法で操作へのアクセス基準のおよそ次のリストに到達します。

1. 所有権 -通常、ユーザーが重要な操作を実行できるのは、自分に属するオブジェクトのみです。 つまり ユーザーとオブジェクトの間には、所有権（所有）の兆候があります。 ホテルの部屋に行くには、鍵が必要です
2. 操作上の可用性 -これは通常、 ACLによって決定されます。 つまり 特定のストレージには、特定のユーザーが原則として何らかのアクションを実行できるかどうかに関する情報があります。 学部長のオフィスには、試験を受けることができる学生のリストがあります
3. 操作の可用性時間 -アクション自体は使用可能ですが、現在は使用できません。 学生はセッション中にのみ試験を受けることができますが、原則として、試験に合格する操作は利用できます。
4. オブジェクトに対する操作の可用性は ACLに類似していますが、ここでは各操作は特定のオブジェクトに関連付けられており、ここでは所有権の基準は大きな役割を果たしていません。 ディーンのオフィスには、特定の科目を履修できる学生のリストがあります
5. 時間制限のあるオブジェクトの操作の可用性 -ほんの一例として、 学部長のオフィスには、特定の日にのみ（自分自身に対して）いくつかの科目を（それぞれに）再受講できる学生のリストがあります

ここで停止しますが、個人の基準ではなくグループの基準を採用する場合、このリストに簡単に2を掛けることができることを示します。 しかし、これは非常に深いです。 あなたはdrれることができます。



今注目！ TheRoleは、最初の2つのアクセシビリティ基準である所有権と運用上の可用性 （ACL）のみを提供します。 残りは大胆に捨てます。

1.5アクセス基準。 所有権の決定

TheRoleは、 オブジェクトの所有権と操作の可用性という 2つのアクセス基準のみで作業を提供します 。 ただし、 オブジェクトを所有するという基準は、厳密に言えば、TheRoleまたは他の承認のためのgemのタスクではないことを認めなければなりません。 オブジェクト間の関係が誰とどのように構成されているか、オブジェクトの所有権の兆候は誰にもわかりません。 ここで普遍的なソリューションを作成することは不可能です。



これは、 所有者の所有権テスト方法を意味しますか？ TheRoleで提供されているこのボックスは、オブジェクト間の関係の最も単純なケースに基づいており、おそらくアプリケーションのすべてのケースに適しているわけではありません。



ownerメソッドは何をしますか？ 、したがって、このユーザーのIDを指定されたオブジェクトのUSER_IDフィールドと一致させようとします。 つまり 次の呼び出しで：

@user.owner?(@page)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際にチェックされます

 @user.id == @page.user_id
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけです。



入力時には、ほとんどのプロジェクトで、ほとんどの場合、この方法が機能します。 ただし、 所有者を取得するために追加の手順を実行する準備をしてください。 望ましい結果を返しました。 これを行う方法は、gemのドキュメントで説明されています 。

なぜアクセス制御基準が1.5だけなのか

「どのアクセス基準が存在しますか？」セクションで示した少なくとも5つのケースをカバーするようなレベルの権利の分配システムを作成するのが素晴らしいと思う場合は、あなたを怒らせることを恐れます。 そのようなシステムを広く使用するために作成する試みは、無意味な行為と同じくらい英雄的です。

• 第一に、そのようなことは誰にとっても実質的に不要であり、そのような組み合わせが実際のリリースを受け取る可能性は低いです。
• 第二に、そのような権利分配システムは、テストでカバーする必要がある膨大な数のケースに関連しています。 そして、それは非常に面倒です。
• 第三に、このようなシステムでは、エンドユーザーがシステムを意識的に制御できるようにするアクセス可能なインターフェースを考案することは非常に困難です。
• 第4に、このソリューションが完成しても、エンドユーザーはこのソリューションが提供するすべての機能を使用しないと確信しています。

そのため、TheRole は操作の可用性の基準を保証する問題のみを解決し、オブジェクトの所有権の基準をチェックする最初のスケッチを提供しようとします 。 確かに99％のケースでこれで十分です。

ACLとは何ですか？

いいえ、明確な説明はありません。 ウィキペディアで見つけることができます。 さらに乾燥します。 ACLはアクセスルールの単なるリポジトリであり、フォームのブール関数acl_checkを適用できます。

 acl_check(@user, @action_name)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

できるのは、trueまたはfalse、 redまたはblue 、goodまたはevil、0または1を返すことだけです。



他のACLシステムと同様に、TheRoleはルールストアに対してacl_checkを提供します（アクセスルールをJSON文字列としてデータベースに保存します）。 特別なことは何もありません。 ただし、TheRoleがルールストレージを整理する方法とその理由を知りたい場合があります。

ACLを保存するための柔軟なデータ構造

最初から、データベースにアクセス制御リストを保存し、このリストを管理する柔軟な手段を提供したい場合、ストックテーブルの形式でデータを保存するのはあまり便利ではないという結論に達しました。 アクセスリストの取得、行ごとの更新、およびその他のすべての操作は、非常にコストがかかります（グラフィカルインターフェイスの観点からのみであっても）。



かつてPHPで、連想配列に注意を向けました。連想配列は、オブジェクトから文字列へ、またはその逆に簡単に変換できます。 このような配列をクライアント上で作成することは簡単で、サーバー上では、フォームを送信した後、ルールの配列が実際に準備できました。 私がしなければならなかったのは、それを文字列に変換してデータベースに保存することだけでした。 クライアントでルールの配列を描画し、サーバーでそれらを操作することは非常に簡単であることが判明しました。



PHPでは、連想配列を操作するためにserialize / unserializeを使用していました。 ルビーでは、JSONとハッシュを使用しています。



すべては非常にシンプルなアクセスリストから始まりました。 たとえば、ユーザーは投稿を作成できますが、コメントコントロールパネル（明示的に定義）にアクセスできず、フォトアルバムを編集できません（明示的に定義せず、ルールが存在しない場合はfalse）。

 { post_create: true, post_delete: true, comments_panel: false }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モデレーターは投稿の作成と削除、コメントコントロールパネルへのアクセスはできますが、フォトアルバムの編集もできません

 { post_create: true, post_delete: true, comments_panel: true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MVCおよびACL。 誰もが見たいものを見る

RORのMVC実装を使用して、 コントローラー/アクションの2レベル構造を毎日確認します（RORの前にコントローラーのコードは同様に配置されていましたが）、コントローラー/アクションの2レベル構造をアクセス制御リストに転送しないことは非常に困難です。 誘惑はとても大きいので、抵抗することはできませんでした。 そのため、TheRoleの最初の実装のACLは、ストレージ用の柔軟なデータ形式に加えて、2層構造も受け取りました。



これはページを作成できるユーザーのロールのように見えますが、何らかの理由でページの編集へのアクセスが彼に制限されていました。

 pages: { index: true, show: true, new: true, create: true, edit: false, update: false, destroy: false }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

TheRoleが2レベルのACL構造を受け取るとすぐに、アプリケーション内のコントローラーアクションへのアクセスを制御することが非常に簡単になりました。 そして、これは、原則として、アプリケーションで最も有用で効果的なチェックの1つです。 そのような検証のためには、 before_filterのアクセス検証メソッドを呼び出すだけで十分です。これには、コントローラーの名前とアクションの名前が渡されます。

 return page_404 if not @user.has_role?(controller_name, action_name)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コントローラのアクセスチェックウォーターフォール

だから。 TheRoleを使用すると、特定のアクションに対するユーザーのアクセスを確認できます。 しかし、問題をより慎重に検討すると、これはコントローラーに与えられるべきアクセスチェックの1つに過ぎないことがわかります。



コントローラーアクションへのアクセスの最初のチェックは、認証gemによって実行されます。 たとえば、DeviseまたはSorcery。 Devise gemは次のように機能します。

 before_action :authenticate_user!, except: [:index, :show]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コントローラーのアクションへのアクセスの2番目のチェックは、権限をチェックするユーザーが存在することが確実な場合にのみ実行する必要があります。 そのため、たとえば、 更新アクションにアクセスしようとすると、最初のbefore_action：authenticate_user！ そして、このフィルターが成功した場合（つまり、ユーザーが存在する場合）、ここで権限をTheRole gemに既に転送できます。

 before_action :role_required, except: [:index, :show]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

role_requiredは、内部的にcurrent_user.has_role？（controller_name、action_name）の形式のチェックを呼び出し、ユーザーに必要な権限がない場合にアクセスエラーのあるページを表示するメソッドです 。



オブジェクトの所有権の3番目のチェック 。 オブジェクトを所有しないと、このオブジェクトを変更（削除または編集）できるコントローラーアクションにアクセスできません。 ただし、オブジェクトがあるまでこのチェックを実行できません。 つまり、最初にオブジェクトを見つける必要があります。

 before_action :set_page, only: [:edit, :update, :destroy]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクト検索は、限られた数のコントローラーアクションで実行されることがわかります。 TheRole gemを介して所有権チェックを行うのが理にかなっているのは、これらのアクションのみです。

 before_action :owner_required, only: [:edit, :update, :destroy]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

set_pageメソッドから、見つかったオブジェクトをowner_requiredメソッドに渡して所有権を確認する必要があることに注意してください。 これはfor_ownership_checkメソッドを使用して行われます。



その結果、かなり信頼性の高いアクセス制限システムを備えた次のコントローラーテンプレートを取得します。

 class PagesController < ApplicationController before_action :authenticate_user!, except: [:index, :show] before_action :role_required, except: [:index, :show] before_action :set_page, only: [:edit, :update, :destroy] before_action :owner_required, only: [:edit, :update, :destroy] # ... code ... private def set_page @page = Page.find params[:id] for_ownership_check(@page) end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

仮想セクションとルール

ACLを2レベルの配列として提示することで、最初のレベルはルールのセクション（グループ）を表し、2番目のルールは対応するブール値を持つルールであり、ロールシステムをアプリケーションコントローラーに非常に正確に統合することができました。 しかし、コントローラのアクションへのアクセスを制御することによってのみ制限することはできません。



ACLデバイスはアプリケーションコントローラーの実際のデバイスを非常に正確に反映できるという事実にもかかわらず、これはACLのすべてのセクションとルールがアプリケーションのデバイスと正確に一致する必要があるという意味ではありません。 ACLに便利なルールグループを絶対に作成し、自由に使用できます。 このようなルールのグループは、コードの実際の構造を反映していないという事実に基づいて、 仮想と呼びますが、論理的な意味のみが付与されています。



以下は、コントローラーアクションへのアクセスを制御し、ページ上のソーシャルボタンの表示を制御するために使用できるユーザーロールの例です。

 pages: { index: true, show: true, new: true, create: true, edit: true, update: true, destroy: true }, social_buttons: { vk: false, twitter: true, facebook: true },
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなアクセスリストの読み取りは、セクションとルールに個別の名前を付けることに注意すれば、非常に簡単です。 ここで、このロールを持つユーザーはPagesコントローラーで基本的なアクションを実行でき、さらにTwitterとFacebookのソーシャルボタンを操作できることがわかります。 しかし、何らかの理由で、ユーザーはVkontakteボタンを使用できません。



TheRoleのコントローラーへの統合がわかった場合、Viewとの統合はさらに簡単です。

 - if current_user - if current_user.has_role?(:social_buttons, :vk) = link_to "Like with VK", "#" - if current_user.has_role?(:social_buttons, :twitter) = link_to "Like with TW", "#" - if current_user.has_role?(:social_buttons, :facebook) = link_to "Like with Fb", "#"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特別な仮想セクション：システムとモデレーター

スーパーユーザーとモデレーターを役割システムに迅速かつ簡単に導入する方法についての質問に困惑せずにはいられませんでした。 TheRole 2で特に重要な仮想セクションを紹介しました。 ある意味では、この決定は松葉杖と見なすことができますが、悪いことは見当たりません。 それは一般的な考え方の統一に違反しません。



アクセスルールのリストにシステムセクションと管理者があるユーザー：真のルールはオブジェクトの所有者と見なされ、アクセスリクエストで常に真を受け取ります。

 system: { administrator: true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モデレーターセクションを持つユーザーは、自分のルールセットで指定されているtrueのセクションルールへのすべての要求に応じてtrueを受け取ります。

 moderator: { pages: true, blogs: false, twitter: true }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり user.has_role？（：pages ,: blabla）やuser.has_role？（：twitter , : blabla）などのクエリでは、このユーザーは常にtrueになります。 しかし、 user.has_role？（：Blogs :: blabla）のようなリクエストは、このユーザーがブログセクションで持つ許可を与えます。 つまり ブログで作業する場合、このユーザーには特権がありません。

ACLコントロールパネル

これで、宝石全体の機能の本質が明らかになり、コントロールパネルを見ることができます。





コントロールパネルは別のgemによって実装され、必要に応じてアプリケーションにインストールされない場合があります。 しかし、一般的なケースでは、インストールするのが理にかなっていると思います。



コントロールパネルには次のものがあります。

• 新しい空の役割を作成する
• 既存の役割に基づいて新しい役割を作成する
• この役割に関する情報の編集
• 特定のロール内で新しいセクションを作成および削除します
• 特定の役割セクション内で新しいルールを作成および削除します
• 1つまたはすべてのシステムロールをJSONファイルにアンロードする
• ロールを含むJSONファイルの読み込み

ACLをバックアップする必要がある場合、役割のインポート/エクスポートが役立ちます。 または、たとえば、TheRoleを使用して、カスタマイズされた役割を複数のプロジェクト間で移動します。

限られた柔軟性

一方で、TheRoleを使用すると、アクセスチェックで使用するルールを作成できます。一貫性がある場合、これらのルールは、アプリケーションで発生していることを意味的に反映します。 一方、TheRoleにはまだ注意すべき多くの制限があります。

• 事前に定義されたアクセス制御パスは、限られたAPIを介してのみ使用できます（これは良いことだと思います）
• ユーザーの役割は1つのみです （これは私の基本的な立場であり、技術的な実装は変更されていません）
• TheRoleはUserモデルでのみ機能します 。 （時間の問題と積極的な貢献者）
• TheRoleはcurrent_userヘルパーでのみ機能します 。 （時間の問題と積極的な貢献者）
• mongoをサポートしていません。 （時間の問題と積極的な貢献者）
• 3つのSQLライクなデータベース（sqlite、mysql、psql）のみをサポート
• ネイティブのjsonデータベース列の使用を意味するものではなく、JSONをテキストとしてのみデータベースに保存します。 （はい、PSQL用のパッチはありますが、特定の動作でコードを詰まらせたくないという願望を考慮して、gemの標準配信にはそれを含めません）

いいでしょう しかし、少なくともユーザーに複数の役割を同時に持たせることは可能ですか？ 申し訳ありませんが、ありません。 これは悪質なアプローチです。 多数の論理的な期待に関連付けられており、人によってまったく異なる場合があります。



1人のユーザーに多くのロールを提供するシステムが必要な場合、これは、あなたがひどく間違えているか、TheRoleが非常に不適切であることを意味します。

謝辞

昨年2014年は私にとって非常に成功しました。オンライン学習という口実の下で、プログラミングに情熱を傾ける才能のある人々と出会い、友達になりました。 ウラジオストックからキエフまで、地理は広大です。 そして、問題を解決し、アイデアを実装するために、人々が意識的にルビー技術を選択することを心から嬉しく思います。 私たちがオープンソースプロジェクトの一部として何かを一緒にやることができてとても嬉しいです。



1）ジェムの3回目のリリースが行われるように、より多くの努力と努力を注いだこれらの人々の1人に感謝したいと思います。 この人の名前はイリヤ・ボンダレンコで 、彼はペルミに住んでいて、私の知る限りテスターとして働いています。 率直に言って、私はイリヤが彼が示した仕事と熱意の程度を素早く解決できたことに嬉しく驚きました。 コラボレーションの一環として、Ilyaはテストの完全な再設計、コード構造の重要な変換の実行、いくつかの重要なバグの修正、ドキュメントの改善、ロードマップgemでの多数の提案を支援しました。 イリヤ 、このレビューがあなたのキャリアの観点からあなたに役立つかどうかはわかりませんが、それでも、高品質な方法でタスクを実行し、優れた結果を達成する方法を知っている人として一般に推薦することができます。 どうもありがとう！



2）さらに、 Sergey Fuchsmanにも感謝します。 どうやら、Sergeyは、TheRole 2からTheRole 3に移行し、小さな問題に遭遇した最初のユーザーの1人でした。 セルゲイ、貴重なフィードバックとTheRoleへの信頼に感謝します。

完了

これについては、私が望んでいたすべてのことについて話していたようです。 意思決定の妥当性と有用性に関する結論。 しかし、少なくともあなたは、MVC構造を持つプロジェクトの認証問題を解決するためのもう1つの（1001st）オプションを知っています。



開発に頑張ってください！