Railsです。Ruby on Railsでモデル内部からcurrent_userにアクセスする

質問

Ruby on Railsのアプリで、きめ細かいアクセス制御を実装する必要があります。個々のユーザーの権限はデータベースのテーブルに保存され、特定のユーザーに読み取りまたは書き込みを許可するかどうかは、それぞれのリソース (すなわちモデルのインスタンス) に決定させるのが最善であると考えました。この決定を毎回コントローラで行うのは、確かにあまりDRYではないでしょう。

問題は、これを行うために、モデルは現在のユーザーにアクセスする必要があり、以下のようなものを呼び出すことです。 may_read?(current_user, attribute_name) . 一般的にモデルはセッションデータにアクセスすることはできませんが。

現在のスレッドで現在のユーザーへの参照を保存するために、かなり多くの提案があります、例えば このブログの記事 . これは確かに問題を解決してくれるでしょう。

近隣のGoogleの結果は、Userクラスで現在のユーザーへの参照を保存するように助言しましたが、これはアプリケーションが一度に多くのユーザーを収容する必要がない人が考え出したものだと思います;)。

長い話を端折ると、モデル内から現在のユーザー（すなわちセッションデータ）にアクセスする私の願いは、私から来たものであるように感じます。 が間違っている .

どう間違っているのか教えてください。

どのように解決するのですか？

あなたの直感で current_user をモデルから外すというあなたの直感は正しいと言えるでしょう。

Danielのように、私は痩せたコントローラと太ったモデルに賛成ですが、責任の分担も明確です。 コントローラの目的は、送られてくるリクエストとセッションを管理することです。 モデルは、「ユーザーxはこのオブジェクトに対してyを行うことができるか」という質問に答えることができなければなりませんが、モデルが current_user . もし、あなたがコンソールにいたらどうでしょう？ cronジョブが実行されている場合はどうでしょうか？

多くの場合、モデル内の適切なパーミッションAPIを使えば、これは1行で処理できます。 before_filters で処理できます。 しかし、物事がより複雑になっている場合は、別のレイヤーを実装したいと思うかもしれません (おそらくは lib/ で）、より複雑な認証ロジックをカプセル化してコントローラの肥大化を防ぎ、モデルがWebのリクエスト/レスポンスサイクルに密結合しすぎるのを防ぐために、別のレイヤーを実装したいと思うかもしれません。