attr_accessible 需要问题和说明答案

【问题标题】：Issue and clarification needed with attr_accessibleattr_accessible 需要问题和说明
【发布时间】：2013-05-13 13:32:10
【问题描述】：

关于 attr_accessible 的安全威胁的文章太多了，我开始怀疑是否应该在其中包含任何属性。这是问题所在。我有一个 Message 模型，它具有以下内容：

attr_accessible :body,:sender_id,:recipient_id

我的messages_controller 中没有update 或edit 操作。通过new 和create 操作，我可以创建一条新消息并将其发送给收件人。只有登录并满足一定条件的用户才能互相发送消息。我在before_filter 的帮助下做到了这一点，而且条件很好。消息已存储并可通过sender 和recipient 查看。完美！

我的问题是，由于:body,:sender_id,:recipient_id 包含在attr_accessible 中，恶意用户能否以某种方式更改原始消息的:body,:sender_id,:recipient_id？我是否应该将这些属性也添加到attr_readonly 以便保存后无法修改？

这个问题一直困扰着我几乎所有的模特。

【问题讨论】：

标签： ruby-on-rails ruby-on-rails-3 ruby-on-rails-3.2 attr-accessible

【解决方案1】：

恶意用户能否以某种方式更改 :body,:sender_id,:recipient_id 原始消息？

这将取决于其他事情而不是attr_accesible。 attr_accesible 将仅过滤允许使用批量分配更新的字段。既然您说您没有任何 update 操作，那么不，现在用户可以编辑消息，因为您始终通过创建操作创建新的 Message。

但是有一些事情你需要关心。 sender_id 是什么？如果您的应用中确实有用户并且他们互相发送消息，那么sender_id 不应该是可访问字段，因为这将允许用户代表其他用户发送消息。您可能希望将该字段排除在 attr_accessible 列表之外并执行以下操作：

m = Message.new params[:message] # body and recipient_id
m.sender_id = current_user.id # this is not mass assignment
m.save
.....

【讨论】：

sender.id == current_user.id。这就是我目前拥有的方式。尽管如此有威胁吗？
那你为什么要把 sender_id 放在列表中呢？这不应该是允许批量分配的字段。

【解决方案2】：

嗯，这取决于您创建模型实例的方式。如果你使用：

FooModel.create(params[:foo])

那么是的，您并不安全，因为即使您没有为这些属性明确提供表单字段，登录用户也可能会向请求传递其他参数。

因此，对于您的情况，使用 sender_id、receiver_id（请求中的值）发布到您的“创建”操作的任何人都可以更改它们除非您在操作中注意此分配 .

【讨论】：

知道了。谢谢。我负责行动中的任务。比如发送者是current_user，而接收者是通过params获取的。但是收件人是通过隐藏字段获取的，并且有一个固定的用户。
那么你应该从 attr_accessible 中删除 sender_id 并在你的操作中明确设置它。