这是否容易受到大规模分配的影响？
我用它来允许用户对条目进行投票：
<% form_tag url_for(entry_votes_path(@entry)), :id => 'voting_form', :remote => true do %>
<%= hidden_field_tag 'vote[user_id]', current_user.id %>
<%= submit_tag 'Vote for this entry', :id => 'voting_button' %>
<% end %>
这是我的控制器代码：
def create
@entry = Entry.find(params[:entry_id])
@vote = @entry.votes.build(params[:vote])
respond_to do |format|
if @vote.save
format.html { redirect_to @entry }
format.js
end
end
end
我有两个问题
如何在不使用隐藏字段的情况下分配
current_user.id？此外，我目前没有在投票模型上使用
attr_accessible或attr_protected。我应该如何保护模型以确保某人无法创建大量选票？现在，投票模型中的所有字段均由params哈希设置 - 我是否应该在entry_id外键上使用attr_protected然后在控制器中单独设置它？
I use this to allow users to vote on an Entry:
<% form_tag url_for(entry_votes_path(@entry)), :id => 'voting_form', :remote => true do %>
<%= hidden_field_tag 'vote[user_id]', current_user.id %>
<%= submit_tag 'Vote for this entry', :id => 'voting_button' %>
<% end %>
This is my controller code:
def create
@entry = Entry.find(params[:entry_id])
@vote = @entry.votes.build(params[:vote])
respond_to do |format|
if @vote.save
format.html { redirect_to @entry }
format.js
end
end
end
I have two questions
How can I assign
current_user.idwithout using a hidden field?Also, I'm not using
attr_accessibleorattr_protectedon the Vote model right now. How should I secure the model to make sure someone can't create a lot of votes? Right now, all the fields in the Vote model are set by theparamshash -- should I useattr_protectedon say, theentry_idforeign key and then set it separately in the controller?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
然后，根据定义，可以从查询字符串进行批量分配。
一般来说，使用 attr_accessible 比 attr_protected 更好。这是因为 attr_accessible 建立了拒绝所有批量分配的默认值，并允许您定义白名单例外。另一方面，attr_protected 会强制您将特定属性列入黑名单。当您修改程序并添加设置了 attr_accessible 的新属性时，如果您需要将该属性列入白名单并忘记，则程序将失败。换句话说，它会安全地失败。或者，如果您添加设置了 attr_protected 的新属性，即使新属性应包含在黑名单中，程序也将正常运行。换句话说，它会不安全地失败。
这里的规则是保护任何属性，如果允许从查询字符串设置这些属性会很危险。保护密钥有助于防止注入新行，但如果您想防止更改现有行的内容，则可能有必要保护其他字段。
可以在 guides.rubyonrails.org 找到这方面的良好参考。
Then, by definition, mass assignment is possible from the query string.
In general, it's better to use attr_accessible than attr_protected. This is because attr_accessible establishes a default of deny-all to mass assignment and lets you define whitelisted exceptions. On the other hand, attr_protected forces you to blacklist specific attributes. When you modify the program and add a new attribute with attr_accessible set, the program will fail if you need to whitelist the attribute and forget. In other words, it fails safely. Alternatively, if you add a new attribute with attr_protected set, the program will work even if the new attribute should have been included in the blacklist. On other words, it fails insecurely.
The rule here is to protect any attribute which it would be dangerous to allow to be set from the query string. Protecting the key helps prevent injection of new rows but it may be necessary to protect other fields if you want to prevent the ability to change the contents of existing rows.
A good reference on this may be found at guides.rubyonrails.org.