blocks|key|1431043|text|我的猜测是，current_user最终是一个用户实例，那么，为什么不将这些权限添加到User模型或您希望拥有要应用或查询的权限的数据模型中呢？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1431044|我的猜测是，你需要以某种方式重构你的模型，并将当前用户作为参数传递，就像这样：|1431045|class+Node+<+ActiveRecord
++belongs_to+:user

++def+authorized?(user)
++++user+&&+(+user.admin?+or+self.user_id+==+user.id+)
++end
end

#+inside+controllers+or+helpers
node.authorized?+current_user|code-block|syntax|javascript|1431046|entityMap^0|6|C|17|4|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|U|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

Well my guess here is that <code>current_user</code> is finally a User instance, so, why don't u add these permissions to the <code>User</code> model or to the data model u want to have the permissions to be applied or queried?

My guess is that u need to restructure your model somehow and pass the current user as a param, like doing:

<pre><code>class Node &lt; ActiveRecord
 belongs_to :user

 def authorized?(user)
 user &amp;&amp; ( user.admin? or self.user_id == user.id )
 end
end

# inside controllers or helpers
node.authorized? current_user
</code></pre>

blocks|key|1431146|text|我使用的是声明式授权插件，它的功能与您在current_user中提到的功能类似，它使用before_filter将current_user拉出并存储在模型层可以访问的位置。看起来像这样：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1431147|#+set_current_user+sets+the+global+current+user+for+this+request.++This
#+is+used+by+model+security+that+does+not+have+access+to+the
#+controller#current_user+method.++It+is+called+as+a+before_filter.
def+set_current_user
++Authorization.current_user+=+current_user
end|code-block|syntax|javascript|1431148|不过，我没有使用声明式授权的模型特性。我完全支持“瘦控制器-胖模型”的方法，但我的感觉是授权(以及身份验证)属于控制器层。|1431149|entityMap^0|K|C|18|D|1M|C|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|V|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|N|$]]

I'm using the Declarative Authorization plugin, and it does something similar to what you are mentioning with <code>current_user</code> It uses a <code>before_filter</code> to pull <code>current_user</code> out and store it where the model layer can get to it. Looks like this:

<pre><code># set_current_user sets the global current user for this request. This
# is used by model security that does not have access to the
# controller#current_user method. It is called as a before_filter.
def set_current_user
 Authorization.current_user = current_user
end
</code></pre>

I'm not using the model features of Declarative Authorization though. I'm all for the "Skinny Controller - Fat Model" approach, but my feeling is that authorization (as well as authentication) is something that belongs in the controller layer.

blocks|key|1216373|text|我在我的一个应用程序中有这个。它只是查找当前的控制器session:user并将其设置为一个User.current_user类变量。这段代码可以在生产环境中使用，而且非常简单。我希望我可以说这是我想出来的，但我相信我是从别处的一个互联网天才那里借来的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1216374|class+ApplicationController+<+ActionController::Base
+++before_filter+do+%7Cc%7C
+++++User.current_user+=+User.find(c.session[:user])+unless+c.session[:user].nil?++
+++end
end

class+User+<+ActiveRecord::Base
++attr_accessor+:current_user
end|code-block|syntax|javascript|1216375|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I have this in an application of mine. It simply looks for the current controllers session[:user] and sets it to a User.current_user class variable. This code works in production and is pretty simple. I wish I could say I came up with it, but I believe I borrowed it from an internet genius elsewhere.

<pre><code>class ApplicationController &lt; ActionController::Base
 before_filter do |c|
 User.current_user = User.find(c.session[:user]) unless c.session[:user].nil? 
 end
end

class User &lt; ActiveRecord::Base
 attr_accessor :current_user
end
</code></pre>

blocks|key|1431328|text|我要说的是，您将current_user排除在模型之外的直觉是正确的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1431329|像Daniel一样，我完全支持瘦控制器和胖模型，但也有明确的职责划分。控制器的用途是管理传入的请求和会话。该模型应该能够回答“用户x可以对此对象执行y操作吗？”这个问题，但是它引用current_user是没有意义的。如果您是在控制台中，该怎么办？如果这是一个cron作业运行怎么办？|1431330|在许多情况下，在模型中使用正确的权限API，这可以通过应用于多个操作的一行before_filters来处理。但是，如果事情变得越来越复杂，您可能希望实现一个单独的层(可能在lib/中)来封装更复杂的授权逻辑，以防止您的控制器变得臃肿，并防止您的模型变得与web请求/响应周期耦合得太紧密。|1431331|entityMap^0|8|C|0|2I|C|0|11|E|2F|4|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|K|$]]

I'd say your instincts to keep <code>current_user</code> out of the model are correct.

Like Daniel I'm all for skinny controllers and fat models, but there is also a clear division of responsibilities. The purpose of the controller is to manage the incoming request and session. The model should be able to answer the question "Can user x do y to this object?", but it's nonsensical for it to reference the <code>current_user</code>. What if you are in the console? What if it's a cron job running?

In many cases with the right permissions API in the model, this can be handled with one-line <code>before_filters</code> that apply to several actions. However if things are getting more complex you may want to implement a separate layer (possibly in <code>lib/</code>) that encapsulates the more complex authorization logic to prevent your controller from becoming bloated, and prevent your model from becoming too tightly coupled to the web request/response cycle.

blocks|key|1431421|text|尽管这个问题已经得到了很多人的回答，但我只想快速补充一下我的两点意见。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1431422|由于线程安全的原因，在用户模型上使用#current_user方法应该小心实现。|1431423|如果您记得使用Thread.current作为一种方式或存储和检索值，那么在User上使用类/单例方法是很好的。但这并不那么简单，因为您还必须重置Thread.current，这样下一个请求就不会继承它不应该继承的权限。|1431424|我想说的是，如果您将状态存储在类或单例变量中，请记住您是在抛出线程安全性。|1431425|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Although this question has been answered by many I just wanted to add my two cents in quickly.

Using the #current_user approach on the User model should be implemented with caution due to Thread Safety. 

It is fine to use a class/singleton method on User if you remember to use Thread.current as a way or storing and retrieving your values. But it is not as easy as that because you also have to reset Thread.current so the next request does not inherit permissions it shouldn't.

The point I am trying to make is, if you store state in class or singleton variables, remember that you are throwing thread safety out the window.

blocks|key|1431510|text|控制器应该告诉模型实例|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1431511|使用数据库是模型的工作。处理web请求，包括了解当前请求的用户，是控制器的工作。|1431512|因此，如果模型实例需要知道当前用户，控制器应该告诉它。|1431513|def+create
++@item+=+Item.new
++@item.current_user+=+current_user+#+or+whatever+your+controller+method+is
++...
end|code-block|syntax|javascript|1431514|这里假设Item有一个用于current_user的attr_accessor。|offset|length|style|CODE|1431515|(注意-我首先在another+question,上发布了这个答案，但我刚刚注意到这个问题是这个问题的副本。)|1431516|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/2513383/access-current-user-in-model^0|0|0|0|0|4|4|D|C|Q|D|0|8|H|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|14|8|@$M|15|N|16|O|P]|$M|17|N|18|O|P]|$M|19|N|1A|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1B|8|@]|9|@$M|1C|N|1D|1|1E]]|A|$]]|$1|S|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

<h1>The Controller should tell the model instance</h1>

Working with the database is the model's job. Handling web requests, including knowing the user for the current request, is the controller's job.

Therefore, if a model instance needs to know the current user, a controller should tell it.

<pre><code>def create
 @item = Item.new
 @item.current_user = current_user # or whatever your controller method is
 ...
end
</code></pre>

This assumes that <code>Item</code> has an <code>attr_accessor</code> for <code>current_user</code>.

(Note - I first posted this answer on <a href="https://stackoverflow.com/questions/2513383/access-current-user-in-model">another question,</a> but I've just noticed that question is a duplicate of this one.)

blocks|key|1431620|text|我的感觉是，当前用户是MVC模型“上下文”的一部分，考虑当前用户，比如当前时间、当前日志流、当前调试级别、当前事务等。您可以将所有这些“模态”作为参数传递到您的函数中。或者通过当前函数体之外的上下文中的变量使其可用。线程局部上下文是比全局或其他作用域变量更好的选择，因为它具有最简单的线程安全性。正如Josh+K所说，线程局部变量的危险在于它们必须在任务完成后被清除，这是依赖注入框架可以为您做的事情。MVC在某种程度上简化了应用程序的实际情况，并不是涵盖了所有内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1431621|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

My feeling is the current user is part of the "context" of your MVC model, think of the current user like of the current time, the current logging stream, the current debugging level, the current transaction etc. You could pass all these "modalities" as arguments into your functions. Or you make it available by variables in a context outside the current function body. Thread local context is the better choice than global or otherwise scoped variables because of easiest thread safety. As Josh K said, the danger with thread locals is that they must be cleared after the task, something a dependency injection framework can do for you. MVC is a somewhat simplified picture of the application reality and not everything is covered by it.

blocks|key|1216842|text|我总是对那些对提问者潜在的业务需求一无所知的人的回答“不要这么做”感到惊讶。是的，通常应该避免这种情况。但在某些情况下，它既合适又非常有用。我自己也刚喝了一杯。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1216843|以下是我的解决方案：|1216844|def+find_current_user
++(1..Kernel.caller.length).each+do+%7Cn%7C
++++RubyVM::DebugInspector.open+do+%7Ci%7C
++++++current_user+=+eval+"current_user+rescue+nil",+i.frame_binding(n)
++++++return+current_user+unless+current_user.nil?
++++end
++end
++return+nil
end|code-block|syntax|javascript|1216845|这将向后遍历堆栈，查找响应current_user的帧。如果没有找到，则返回nil。可以通过确认期望的返回类型，以及可能通过确认框架的所有者是一种控制器类型来使其更加健壮，但通常情况下，它只是一种花哨的工作。|offset|length|style|CODE|1216846|entityMap^0|0|0|0|D|C|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@$K|U|L|V|M|N]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I'm always amazed at "just don't do that" responses by people who know nothing of the questioner's underlying business need. Yes, generally this should be avoided. But there are circumstances where it's both appropriate and highly useful. I just had one myself.

Here was my solution:

<pre><code>def find_current_user
 (1..Kernel.caller.length).each do |n|
 RubyVM::DebugInspector.open do |i|
 current_user = eval "current_user rescue nil", i.frame_binding(n)
 return current_user unless current_user.nil?
 end
 end
 return nil
end
</code></pre>

This walks the stack backwards looking for a frame that responds to <code>current_user</code>. If none is found it returns nil. It could be made more robust by confirming the expected return type, and possibly by confirming owner of the frame is a type of controller, but generally works just dandy.

blocks|key|1216886|text|古老的线程，但值得注意的是，从Rails5.2开始，有一个内置的解决方案:当前的单例模型，在这里介绍：https://evilmartians.com/chronicles/rails-5-2-active-storage-and-beyond#current-everything|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1216887|entityMap|0|LINK|mutability|MUTABLE|url|https://evilmartians.com/chronicles/rails-5-2-active-storage-and-beyond#current-everything^0|1F|2I|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Ancient thread, but worth noting that starting in Rails 5.2, there's a baked-in solution to this: the Current model singleton, covered here: <a href="https://evilmartians.com/chronicles/rails-5-2-active-storage-and-beyond#current-everything" rel="noreferrer">https://evilmartians.com/chronicles/rails-5-2-active-storage-and-beyond#current-everything</a>

blocks|key|1216931|text|我参加这个聚会已经很晚了，但是如果你需要细粒度的访问控制或者拥有复杂的权限，我绝对推荐你使用Cancancan+Gem：https://github.com/CanCanCommunity/cancancan|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1216932|它允许你在你的控制器中定义每个动作的权限，因为你可以在任何控制器上定义当前的能力，你可以发送任何你需要的参数，比如current_user。您可以在ApplicationController中定义一个泛型current_ability方法并自动进行设置：|style|CODE|1216933|class+ApplicationController+<+ActionController::Base
++protect_from_forgery+with:+:null_session
++def+current_ability
++++klass+=+Object.const_defined?('MODEL_CLASS_NAME')+?+MODEL_CLASS_NAME+:+controller_name.classify
++++@current_ability+%7C%7C=+"#{klass.to_s}Abilities".constantize.new(current_user,+request)
++end
end|code-block|syntax|javascript|1216934|这样，您就可以将UserAbilities类链接到UserController，将PostAbilities链接到PostController，依此类推。然后在其中定义复杂的规则：|1216935|class+UserAbilities
++include+CanCan::Ability

++def+initialize(user,+request)
++++if+user
++++++if+user.admin?
++++++++can+:manage,+User
++++++else
++++++++#+Allow+operations+for+logged+in+users.
++++++++can+:show,+User,+id:+user.id
++++++++can+:index,+User+if+user
++++++end
++++end
++end
end|1216936|这是一个很棒的宝石！希望它能帮上忙！|1216937|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/CanCanCommunity/cancancan^0|1O|18|0|0|1L|C|22|L|2U|F|0|0|8|D|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|D|3|E|5|6|7|14|8|@$A|15|B|16|F|G]|$A|17|B|18|F|G]|$A|19|B|1A|F|G]]|9|@]|C|$]]|$1|H|3|I|5|J|7|1B|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|1C|8|@$A|1D|B|1E|F|G]]|9|@]|C|$]]|$1|O|3|P|5|J|7|1F|8|@]|9|@]|C|$K|L]]|$1|Q|3|R|5|6|7|1G|8|@]|9|@]|C|$]]|$1|S|3|-4|5|6|7|1H|8|@]|9|@]|C|$]]]|T|$U|$5|V|W|X|C|$Y|Z]]]]

I am so very late to this party, but if you need fine-grained access control or have complex permissions I would definitely recommend the Cancancan Gem:
<a href="https://github.com/CanCanCommunity/cancancan" rel="nofollow noreferrer">https://github.com/CanCanCommunity/cancancan</a>
It allows you to define permissions at every action in your Controller to whatever you want, and since you define the current ability on any controller you can send any parameters you need, like the <code>current_user</code>. You can define a generic <code>current_ability</code> method in <code>ApplicationController</code> and set up things automagically:
<pre><code>class ApplicationController &lt; ActionController::Base
 protect_from_forgery with: :null_session
 def current_ability
 klass = Object.const_defined?('MODEL_CLASS_NAME') ? MODEL_CLASS_NAME : controller_name.classify
 @current_ability ||= &quot;#{klass.to_s}Abilities&quot;.constantize.new(current_user, request)
 end
end
</code></pre>
This way, you can have a <code>UserAbilities</code> Class linked to your UserController, PostAbilities to your PostController and so on. And then define the complex rules in there:
<pre><code>class UserAbilities
 include CanCan::Ability

 def initialize(user, request)
 if user
 if user.admin?
 can :manage, User
 else
 # Allow operations for logged in users.
 can :show, User, id: user.id
 can :index, User if user
 end
 end
 end
end
</code></pre>
It's a great Gem! hope it helps!

I need to implement fine-grained access control in a Ruby on Rails app. The permissions for individual users are saved in a database table and I thought that it would be best to let the respective resource (i.e. the instance of a model) decide whether a certain user is allowed to read from or write to it. Making this decision in the controller each time certainly wouldn’t be very DRY. 
The problem is that in order to do this, the model needs access to the current user, to call something like <code><code>may_read</code>?(<code>current_user</code>, <code>attribute_name</code>)</code>. Models in general do not have access to session data, though. 

There are quite some suggestions to save a reference to the current user in the current thread, e.g. in <a href="http://clearcove.ca/blog/2008/08/recipe-make-request-environment-available-to-models-in-rails/" rel="noreferrer">this blog post</a>. This would certainly solve the problem. 

Neighboring Google results advised me to save a reference to the current user in the User class though, which I guess was thought up by someone whose application does not have to accommodate a lot of users at once. ;)

Long story short, I get the feeling that my wish to access the current user (i.e. session data) from within a model comes from me <a href="http://lemonodor.com/archives/images/mccarthy-youre-doing-it-wrong-s.jpg" rel="noreferrer">doing it wrong</a>.

Can you tell me how I’m wrong?

Rails: Access to current_user from within a model in Ruby on Rails

身份验证

数据库

Kernel

我需要在Ruby on Rails应用程序中实现细粒度的访问控制。单个用户的权限保存在数据库表中，我认为最好让相应的资源(即模型的实例)决定是否允许某个用户对其进行读写操作。每次在控制器中做这个决定肯定不会很枯燥。问题是，为了做到这一点，模型需要访问当前用户，以调用类似于may_read?(current_user, ...

问Rails:在Ruby on Rails中从模型中访问current_user
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Rails:在Ruby on Rails中从模型中访问current_userEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Rails:在Ruby on Rails中从模型中访问current_user
EN