Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Ruby

attr_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!

Wait, 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!

2 Answers

Jason Seifer
STAFF
Jason Seifer
Treehouse Guest Teacher

Hey 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.

Hi 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?

I'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

Yessssss...thanks so much for asking this question!