On Thu, Jun 11, 2009 at 4:20 PM, C, D.<[email protected]> wrote:
>>> the controller I have kept it simple and did a >>> @user.update_attributes(params[:user]), expecting that the >>> authenticity_token would never allow any params to be posted that I >>> didnt allow through my form. >> >> The forgery protect_from_forgery protects against is cross site >> request forgery, ie. completely unrelated to the problem you're >> tackling. You may be interested in attr_protected/attr_accessible. >> >> Fred > > Alright that makes sense. I might have misunderstood the PFF function. > > But I still feel this is a grossly underestimated security hole. It > doesn't seem very ruby-esque to shield the 'forbidden' attributes with > attr_accessors. Since on one form you might be allowed to change it, yet > on a different one you wont have that field supplied. > > You obviously dont want to hard code your data entry restrictions on > controller level. That violates the DRY principle. When I change the > form to allow someone to edit an extra field, I also have to 'open up' > this field in the controller. The current solution is a trade-off: it is a simple solution that covers most use cases. Often the account_id of your User model is protected, period. That's what the current design supports. There was a recent discussion in the core mailing list about possible ways to make this a little more flexible: http://groups.google.co.uk/group/rubyonrails-core/browse_thread/thread/3b6818496d0d07f1/0d20bb9236fe59af#0d20bb9236fe59af but no conclusion except for some workarounds to the current solution when you need them. --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
