My app relied on the security vulnerability fixed in Rails 3.0.1.
While I did specify attributes such as name and email, my main goal
was to use an existing record by specifying the id. The 3.0.1 patch
does not make it possible to specify id in nested attributes. It now
raises a raise_nested_attributes_record_not_found whenever the id
attribute is present. The intention of the patch was to deny updates
to other attributes when the id is specified; i.e. {:id => 1, :name =>
'pedo bear' }. That was off course a needed security improvement but
was the intention also not to use nested_attributes for existing
objects?The API docs http://api.rubyonrails.org/classes/ActiveRecord/NestedAttributes/ClassMethods.html#method-i-accepts_nested_attributes_for "It also allows you to update the avatar through the member: params = { :member => { :avatar_attributes => { :id => '2', :icon => 'sad' } } } member.update_attributes params[:member] member.avatar.icon # => 'sad'" And "If the hash contains an id key that matches an already associated record, the matching record will be modified:" Seems like this was not just a security vulnerability but intended and documented behavior. What should be done here? 1. Existing objects must be saved with child_id = # not child_attributes = { :id => 3} 2. allow id in nested attributes but do not accept other attributes. Either way the docs should be updated. (And so must my API docs...) Patch: http://rubyonrails-security.googlegroups.com/attach/e307ee2102f2e4be/3-0-nested_attributes.patch?view=1&part=4 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
