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
"It also allows you to update the avatar through the member:
"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...)
Seems like this was not just a security vulnerability but intended and
documented behavior.
It was poorly considered intended behaviour because of the problems
with :allow_destroy. That's not to say we can't come up with something
nicer, but the original patch isn't it
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.
The problem with allowing id in the associations is how can we, a
framework, scope it sensibly? In some cases assigning any record is
fine. for example picking a category for a bug report, triggering
category.find is fine. The other side of the coin is something like
picking a bank account to assign a payment to. Unscoped finders there
would be a huge problem.
Either way the docs should be updated. (And so must my API docs...)
For now the docs should probably just be updated, and if someone wants
to figure out a way to re-enable a sub-set of this functionality for
3.1, we can experiment and analyse here before we push any releases.
