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.
On May 19, 6:07 pm, brianp <brian.o.pea...@gmail.com> wrote: > 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! > > On May 19, 12:00 am, Sharagoz <shara...@gmail.com> wrote: > > > > > 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. > > > On May 19, 5:09 am, brianp <brian.o.pea...@gmail.com> wrote: > > > > 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 > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Ruby on Rails: Talk" group. > > > To post to this group, send email to rubyonrails-t...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > rubyonrails-talk+unsubscr...@googlegroups.com. > > > For more options, visit this group > > > athttp://groups.google.com/group/rubyonrails-talk?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Talk" group. > > To post to this group, send email to rubyonrails-t...@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-talk+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/rubyonrails-talk?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-t...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/rubyonrails-talk?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
