2

そのため、ユーザーとユーザーが変更するオブジェクトとの間にいくつかの権限を実装しました..そして、ビュー/コントローラーとモデルとの結合を減らしたいと思います(上記の権限を呼び出します)。before_save//before_createコールバックにパーミッション機能の一部を実装するbefore_destroy。しかし、権限はユーザー ( current_user.can_do_whatever?) に関連付けられているため、どうすればよいかわかりませんでした。

current_userこのアイデアは、具体的にはコントローラーレベルであるため、結合を増加させる可能性さえあります。

最初にこれをやりたかった理由は次のとおりです。コントローラー全体で、ユーザーがsave/ create/を実行できるかどうかを確認する必要がありますdestroy。では、Rails が既に行っているようにsave/ create/に対して false を返し、モデル オブジェクトにエラーを追加して、Rails の検証と同様に false を返すのはなぜでしょうか?destroy.save

Idk、これは良いですか、それとも悪いですか？これを行うより良い方法はありますか？

4

2 に答える 2

4

コントローラにユーザーの権限をチェックさせます。モデルに承認ロジックを処理させると、より多くの結合が発生します (場所が異なるだけで、現在のユーザーを取得するためにコントローラーへの結合がまだ存在します)。特権のチェックは、実際にはモデルの内部ロジックではありません。

類似: OS (実際にはすべてのコントローラーの母体) がアクセスを処理するのではなく、読み書きできるかどうかをチェックするのがファイルの責任であると想像してみてください。

よりクリーンなコントローラーが必要な場合は、(たとえば) 現在のユーザーに基づいて CRUD アクションへのアクセスを制限する一般化された before_filters を作成できます。

于 2012-06-12T22:35:57.370 に答える
2

フランビーノはあなたにパーティーラインを与えました:)しかし私に私の2セントを加えさせてください。モデルの一部としてアクセス制御ロジックを検討することは確かに可能です。

モデルの検証は、クラッドアクションに対するユーザーの権限を操作する方法を確認する方法です。これの欠点は、アクセスロジックが通常モデル間で一般化されるという事実です。したがって、きちんとしたカンカン能力ファイルのようにモデルを抽象化するのが好きです。

あなたは実際にあなたのケーキを持って、あなたの操作自体をモデルの多形的な関連にすることによってそれを食べることができます。これは、ほとんどの監査/バージョン管理システムが実装されている方法です。 https://github.com/collectiveidea/audited これを拡張して、アクセス制御ロジックを監査クラスの検証に配置できるため、1か所にまとめられます。監査されたgemは、コントローラーのフィルターの周りにオブザーバーを使用することで、現在のユーザーをモデルレベルに渡すための巧妙な方法も提供します。 https://github.com/collectiveidea/audited/blob/master/lib/audited/sweeper.rb しかし、他の方法もありますhttps://github.com/bokmann/sentient_userしばしばハッキーと見なされます。

警告

  • いずれの場合も、current_userが正しく定義されていない場合に、モデルが要求サイクル外（バックグラウンドルーチン、cronjob、コンソール）で操作される状況を防ぐ必要があります。

  • 通常、アクセス違反を検証エラーで処理するのではなく、標準のhttpステータスコード応答を使用します。

  • 第3に、Webアプリの設定では、通常、フォームを介してオブジェクトを操作します。通常、アクセスを制御して、更新フォームと言うことができます。実際には、通常、更新自体と同じアクセス権が組み合わされています（新規/作成および編集の一般的なエイリアスを持つこともできます）。 / update）したがって、後者が検証で処理される場合、この一般化されたアクセスロジックは失われます。言うまでもなく、読み取りアクセスロジックはモデル検証では処理できません。

お役に立てれば

于 2012-06-13T11:50:06.740 に答える