Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
Thomas MacFarlane
2,430 Pointsattr_accessible -> strong_parameters in Rails4 in Treebook - Gonna have an aneurism
So I have Rails4 and would like to have my parameters protected just like they are using the old attr_accessible method.
I've looked on the forums and implemented the changes in the controller, but the problem is, if I didn't do anything at all to start with, it accepts the first_name last_name automatically.
How do I setup strong_parameters so that everything isn't automatically whitelisted?
I would like to see the error message, make the change in the code, and then see a successful result.
Pleaaaaaaase help, I'm going mad here!
2 Answers
Jason Seifer
Treehouse Guest TeacherHey Thomas MacFarlane we use rails 3.2.12 in the project for treebook. We're working on updated content right now but I recommend reading the strong_parameters section of the action controller guide in the mean time. In order to add an attribute to the list of available attributes, open up your controller and see where the attributes are defined. You can then add it to the permitted or denied list.
Thomas MacFarlane
2,430 PointsHi Jason Seifer , I know you use Rails3 for Treebook, but like to try to work with the latest versions of things. I've read the documentation on strong_parameters in regards to Rails and Devise, but have a fair bit of difficulty understanding what's being discussed.
I think though, that I have realised the difference. In Rails3, including parameters that were not whitelisted would cause an error such as seen in the video. But in Rails4, it appears that non-permitted parameters are 'stripped' out and given a value of 'null', so that if I include first_name, last_name and profile_name fields in the sign_up page without whitelisting them, the request will still process and the user will be added to the database, however the first_name, last_name and profile_name fields will all have a value of 'null', until permitted via the controller.
Is this correct?
Thomas MacFarlane
2,430 PointsI've discovered that this is in fact correct. Parameters not whitelisted are given a value of null when added to the database. The code for Treebook, in application_controller.rb is
before_filter :configure_permitted_parameters, if: :devise_controller?
protected
def configure_permitted_parameters
devise_parameter_sanitizer.for(:sign_up) << :first_name << :last_name << :profile_name
end
Natalie Arellano
3,362 PointsYessssss...thanks so much for asking this question!
Thomas MacFarlane
2,430 PointsThomas MacFarlane
2,430 PointsWait, wait wait wait... I might have just had an epiphany... Does the change to strong_parameters just mean that extra parameters passed are nullified? So when an entry gets created in the database, unless the extra parameters have been included in the strong_parameters of the controller, they get a value of null.
So instead of getting an error... the sign_up function passes, while 'disabling' the unauthorised parameters?
And configuring the controller file allows these parameters to accept values? Please someone tell me if I'm right!