5

私は Rails Web アプリケーションに取り組んでおり、現在約 20 人のユーザーが使用しています。

アプリケーションの一部は一部のユーザーのみがアクセスできるため、acts_as_authenticated プラグインを使用して実装した基本的な承認フレームワークが既に用意されています。

ユーザーの権限は、所属する部門によって異なります。たとえば、管理者はアプリケーションのすべての部分にアクセスできますが、会計は会計関連の部分にのみアクセスでき、営業は販売関連の部分にのみアクセスできます。

一方、ユーザーには、権限が不十分なアクションへのリンクが表示されます。たとえば、営業部門の担当者は、メイン メニューに財務記録へのリンクが表示されますが、クリックしても何も起こりません。これは、acts_as_authenticated を使用してユーザー権限を照会する効率的な方法がないためです。

これを2つの方法で変更したい：

  1. よりきめ細かい認可を導入したいと考えています。現在、承認はコントローラ レベルで行われます。アクションまたはモデルレベルでこれを行いたいです。たとえば、営業部門の担当者は、支払いの作成と更新はできるが、削除はできないようにしたいと考えています。

  2. ユーザー権限を効率的に照会できるようにしたいので、インターフェイスから不要な (そして紛らわしい) リンクを削除できます。

これを実装する最もエレガントな方法は何だと思いますか?

Rails 固有の回答は必要ありません。データ駆動型アプリケーションでこれをどのように実装する必要があるかを知りたいだけです。

最後に、現在の実装方法は次のとおりです。

def authorized?
  current_user.role.foo? or current_user.role.bar?
end

そして、これが私の最初のアイデアです。これは、これを解決するための最良の方法ではないと思います。

+------------+------------+---------+
| | 部門 | コントローラー | アクション | アクション |
+------------+------------+---------+
| | 会計 | 支払い | インデックス |
| | 会計 | 支払い | 新しい |
| | 会計 | 支払い | 作成 |
| | 会計 | 支払い | 編集 |
| | 会計 | 支払い | アップデート |
| | 会計 | 支払い | 破壊する |
| | 販売 | 支払い | 新しい |
| | 販売 | 支払い | 作成 |
| | 販売 | 支払い | 編集 |
| | 販売 | 支払い | アップデート |
+------------+------------+---------+

また

+------------+----------+-------+--------+------+- -------+--------+
| | 部門 | モデル | リスト | 作成 | 読む | アップデート | 削除 |
+------------+----------+-------+--------+------+- -------+--------+
| | 会計 | 支払い | 真 | 真 | 真 | 真 | 真 |
| | 販売 | 支払い | 偽 | 真 | 真 | 真 | 偽 |
+------------+----------+-------+--------+------+- -------+--------+
4

3 に答える 3

3

私が理解しているように、承認の基本概念は役割です。Role はさまざまなことを表現できます。

  1. システム全体に対するユーザーの関係 (例: システムの管理者になる)
  2. ユーザーとある種のエンティティとの関係 (例: コメントのモデレーターになるため)
  3. ユーザーと特定のエンティティとの関係 (たとえば、リソースの所有者になるなど)
  4. その他の複雑な関係 (例: リソースの所有者であるユーザーのフレンドになる)
  5. そのユーザーは何らかの属性を持っているか、特定の方法でメッセージに応答します (たとえば、10 代になるなど)。

非常にきめ細かい認証システムでは、上記の基準のいずれかに基づいてユーザーのロールを定義できるようにする必要があります。さらに、ユーザーに複数の役割を設定できるようにする必要があります。(Rails の認可プラグインの最も単純な形式では、通常、最初の種類のロールのみを定義して、ユーザーに 1 つのロールのみを設定できます。)

承認のもう 1 つの部分は、ユーザーが何らかの役割 (一連の役割) に適合するかどうかに基づいて、コードのどの部分を実行するか (または実行しないか) を決定するメカニズムです。このメカニズムを適用するには、承認が行われるポイントを見つけ、コードを実行する必要があるロールまたは実行しないロールを選択する必要があります。

Railsで私にとってうまくいく方法は、モデルレベルで役割を定義し、承認メカニズムを残すことです（承認したいコードの部分に許可された役割を設定し、現在のユーザーがその部分の実行を許可されている役割を持っているかどうかを尋ねます) 完全にコントローラー/ビュー用です。

これには、今述べたすべての可能性が組み込まれている微調整した rails-authorization-plugin を使用します (さまざまな種類の役割、1 人のユーザーに対する多くの役割、コントローラーおよびビュー レベルでの承認)。

于 2008-11-11T14:57:58.583 に答える
0

アクセスの制御点として、「ファンクションポイント」または「機能」の概念をモデルに導入する必要がある場合があります。「機能」には、階層を形成するためのオプションの「親機能」が含まれる場合があります。機能とは何かを判断し、プログラムで権限を確認することができます。これにより、メニューを描画する前に機能レベルのアクセスを確認できるため、ユーザーはアクセスが許可されていないページへのリンクを見ることができなくなります。

同様の状況/解決策はここで説明されています

于 2008-11-11T02:53:12.290 に答える
0

2 つの提案のうち、最初のオプションは、モデル レベルのアクションではない可能性があるアクションを追加できるため、少し良く見えます。2 番目のモデルでは十分に機能しないケースに遭遇すると思います。スキーマを変更するか、アプリ全体にパーミッション ロジックを散りばめ始める必要があります (例: 「「作成」アクセス権のないユーザー」メソッド xxx も実行できません」)

解決策があまり DRY に見えない理由は、繰り返しがあるからだと思います。

  1. 部署名には、
  2. 部門能力で

#1 に関しては、部門テーブルを作成し、各部門に ID を付与するのが理にかなっています。

＃2に関しては、最初のコメントに同意します。おそらく、さまざまなコントローラーとアクションを機能グループにクラスター化し、ユーザーと機能の間に多対多の関係 (マッピング テーブル) を設定できます。関数は、許可するアクション/コントローラーと 1 対多の関係を持ちます。これにより、最小限の繰り返しで、「経理と営業はすべての財務テーブルを読み取れるようにする必要があります」などと言うことができます。

于 2008-11-11T07:46:58.860 に答える