モデルのセキュリティロジックを扱うコードを混在させるのは悪い設計ですか？現在のユーザがコントローラ層内current_user方法から取得さbefore_saveコールバックセキュリティロジックとRuby on Railsのモデルを混在させる？
例。
current_user.has_permission? :edit_pageが偽editor_idは変更がモデルは、アプリケーション内の唯一のセキュリティチェックではない別のテーブルにをログに記録されcurrent_user.id
注：モデルレベルとコントローラレベルの間の唯一の違反は、current_userメソッドです。私が取り組んでいるアプリケーションは匿名ユーザーを許可しません。
セキュリティロジックをモデルに入れるのは悪いデザインだとは思いません。ビジネスロジックをそこに置くと、セキュリティロジックをビジネスロジックの一種と見ることは間違いありません。あなたは確かにコントローラやビューのすべてを望んでいない、あなたはskinny controller, fat modelのアプローチに従いたいと思う。
あなたのモデルは、アプリケーションロジックのまとまりの塊として単独で存在する必要があります。モデルをRailsコンソールから完全にドライブできるはずです。また、モデルにセキュリティロジックを持たせることで単体テストが容易になります。
あなたのモデルが直接アクセスできるようになっているかどうかによって異なります。もしそうであれば、恐らくミックスインを介して、おそらくモデルの主な関心事にいくらか直面する可能性があるので、セキュリティ上の懸念を意識しているはずです。
モデルが見えなくなり、コントローラにセキュリティロジックが既にある場合は、モデルをそのままにしておきます。
MVCフレームワークのモデルは、すべてのビジネスロジックを完全に含むはずです。うまく設計されたMVCアプリケーションでは、少なくとも論理的には、ビジネスロジックを実装することなく、異なるコンテキストでモデルを再利用できるようにする必要があります。
認可、入力の検証、監査のロギングはすべてです。は非常に間違いなくビジネスロジックですので、モデルで処理する必要があります。
一方、認証、暗号化、暗号化ハッシュなどはではないと思われます一部のモデルです。セキュリティのこれらの側面は、コアビジネスロジックの一部ではなく、通常はアプリケーションインターフェイスの一部です。