# Accepts nest attributes & attr\_accessible

**URL:** <https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838>\
**Category:** Rails\
**Created:** [May 19, 2010, 5:11am UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838 "2010-05-19T05:11:29Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![brianp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/94ad74/32.png) [@brianp](https://www.ruby-forum.com/u/brianp)\
**Post date:** [May 19, 2010, 5:11am UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838/1 "2010-05-19T05:11:29Z")

</div>

Hey,  
Just going over some of the accepts of accepts\_nested\_attributes\_for  
& attr\_accessible.

I found with the form and models I’ve been working on it would be  
great if I could use accepts\_nested\_attribtues but I want to propose  
my case where I just can’t make it work. And for secretory reasons  
wonder where it would ever work for that matter.

So below. We have a household setup. We would have a Family object  
with an id. Now if we were to create one person for the family we  
could do it easily with:

@family = Family.new  
@family.persons.new(params[person])

But what if we wanted to add a person and a child at the same time via  
nested parameters? We won’t be able to. As the childs family\_id field  
is protected we won’t be able to mass assign with the nested  
parameters. I can’t think of a time I would ever be creating a  
completely “open” object that wouldn’t have a single protected  
parameter. So when do the nested\_attributes come in handy besides when  
your model is un-secure?

(This is just me learning there very well might be perfect places for  
this, I am just wondering where)

class Person \< ActiveRecord::Base  
validates\_presence\_of :name, :family\_id

has\_many :children  
belongs\_to :family

accepts\_nested\_attributes\_for :children

attr\_accessible :name  
end

class Child \< ActiveRecord::Base  
belongs\_to :person  
belongs\_to :family

validates\_presence\_of :name, :family\_id

attr\_accessible :name  
end

class Family \< ActiveRecord::Base  
has\_many :persons  
has\_many :children (childs?)

attr\_protected :id  
end

cheers,  
brianp

---

<div class="post-metadata">

**Author:** ![brianp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/94ad74/32.png) [@brianp](https://www.ruby-forum.com/u/brianp)\
**Post date:** [May 19, 2010, 9:02am UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838/2 "2010-05-19T09:02:07Z")

</div>

Why does Child even have the family\_id attribute? Can’t you get the  
child’s family through it’s person (parent)?  
Unless the child can belong to a different family than the person,  
this is an unnecessary association.

Anyway, that doesn’t really answer the question.  
accepts\_nested\_atrributes\_for and attr\_protected on the foreign keys  
doesn’t work together. My question is: Why are you putting  
attr\_protected on the foreign\_keys? To prevent users from being able  
to move a child to a different parent when editing its attributes? If  
so, I recommend you use attr\_readonly instead.

---

<div class="post-metadata">

**Author:** ![brianp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/94ad74/32.png) [@brianp](https://www.ruby-forum.com/u/brianp)\
**Post date:** [May 19, 2010, 6:08pm UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838/3 "2010-05-19T18:08:19Z")

</div>

Yeah the objective protecting the foreign keys are not letting the  
Users make the changes. Maybe an admin of the app could say a person  
or child has changed families (parents do split up). But we don’t want  
some smart child using curl and changing his family to any family id  
he wants on his own. And thereby getting access to another families  
options/pages or capabilities.

In my particular applications case as you’ve seen example code. I have  
dealers and users. Users belong to a dealer. Users would have foreign  
keys attr\_protected. Becuase at no point is a user ever changing what  
dealer it belongs to. But if the keys can be mass assigned. Then isn’t  
the app then vulnerable to someone creating a user that could belong  
to ANY dealership. Then gaining access to another dealerships admin  
panel ?

But if the id can’t be mass assigned then it cannot be created through  
the dealer via nested attributes. Which makes me think the only models  
that can be assigned via nested attributes are un-secure and  
vulnerable to mass-assignment attacks.

attr\_readonly does not look like it would solver the problem. As again  
on the initial create any use could assign any foreign key to  
themselves on the initial create.

Maybe i’m wrong here and maybe this just isn’t a concern at all  
somehow. But after reading the security issues on mass-assignment I  
don’t understand how there not vulnerabilities. If a user can change a  
foreign key which is used for authorization purposes. Then there  
changing privileges for them self.

Thanks for all the replies Sharagoz your really cleaning up my posts  
=) ie helping me understand rails better everyday!

---

<div class="post-metadata">

**Author:** ![brianp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/94ad74/32.png) [@brianp](https://www.ruby-forum.com/u/brianp)\
**Post date:** [May 20, 2010, 12:16am UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838/4 "2010-05-20T00:16:36Z")

</div>

Ahhhh yeah i guess that does make sense.

Now what about…I think well trying to come up with my counter-piece  
I answered my own question so let me see if I have it correct:

If the user was created in context of the dealer like you said. Then  
in the dealers control panel the user can update there profile. If the  
profole was updated by finding the user and updating directly then  
this could be a secuirty issue as they could change the dealer id at  
that point by sneaking in :dealer\_id.  
BUT  
If the user updates the profile and it’s processed via the dealer then  
this would not be an issue because it would still be in context.  
how would this look in the controller?  
@dealer.users.find(3).update\_attributes(params[:update\_user\_form])  
?

Thanks,  
brianp

---

<div class="post-metadata">

**Author:** ![brianp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/94ad74/32.png) [@brianp](https://www.ruby-forum.com/u/brianp)\
**Post date:** [May 20, 2010, 8:11am UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838/5 "2010-05-20T08:11:16Z")

</div>

On May 20, 12:14 am, brianp [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> If the user updates the profile and it’s processed via the dealer then  
> this would not be an issue because it would still be in context

That is correct, however if you set the dealer\_id to readonly, then it  
is not possible for the user to change it anyway, so  
User.find(3).update\_attributes(params[:user]) is fine

---

<div class="post-metadata">

**Author:** ![brianp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/94ad74/32.png) [@brianp](https://www.ruby-forum.com/u/brianp)\
**Post date:** [May 23, 2010, 12:31pm UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838/6 "2010-05-23T12:31:43Z")

</div>

Hi all,

I want to invite you to check out ResourceAwareness, a small gem that  
makes available information about a Rails application’s resources (as  
defined by the ‘resource/s’ routing DSL methods) at  
Rails.application.resources.

> **[GitHub - ingoweiss/resource\_awareness: Makes information about a Rails...](https://github.com/ingoweiss/resource_awareness)**
>
> Makes information about a Rails application's resources (as defined via the 'resource(s)' routing DSL methods) available via Rails.application.resources - GitHub - ingoweiss/resource\_aw...

You can find a brief introductory post about it here:

[http://blog.ingoweiss.com/2010/05/10/resource-awareness.html](http://blog.ingoweiss.com/2010/05/10/resource-awareness.html)

There is also another post with a small example (dynamic ActiveResource  
client creation) for the kind of things that become possible once this  
resource information is available:

[http://blog.ingoweiss.com/2010/05/12/resource-awareness-and-active-resource.html](http://blog.ingoweiss.com/2010/05/12/resource-awareness-and-active-resource.html)

Best Regards,  
Ingo W.

> **[ingoweiss - Overview](https://github.com/ingoweiss)**
>
> ingoweiss has 23 repositories available. Follow their code on GitHub.

---

<div class="post-metadata">

**Author:** ![brianp](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/94ad74/32.png) [@brianp](https://www.ruby-forum.com/u/brianp)\
**Post date:** [May 19, 2010, 6:49pm UTC](https://www.ruby-forum.com/t/accepts-nest-attributes-attr-accessible/188838/7 "2010-05-19T18:49:54Z")

</div>

This is not a problem if you are always creating users in context of  
dealers and validating that the one doing the creation is allowed to  
manage the data for the dealer in question.  
@dealer.users.create(params[:user])  
This ensures that the users dealer\_id is set to @dealer.id, even if  
somebody tries to be clever and add dealer\_id to the post request.