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
Olly Whitman
12,919 PointsRuby on Rails – Treebook. attr_accessible and Rails4
I was wondering what is the impact of not including attr_accessible because I'm using Rails 4, not 3?
After getting an error message I installed gem 'strong_parameters' which seemed to completely break my rails server, which I have managed to undo.
Am I missing a large part of the lesson if I continue without the attr_accessible being defined? My app seems to be working fine so far.
3 Answers
Adam Kelm
29,082 PointsI found out the hard way--omitting the attr_accessible does terrible things to your application. In Rails 4, they moved the permissions from the models, where Treehouse edits them, to the controllers, where they make more sense. So in Rails 4, it seems like all attributes are whitelisted, and strong_parameters would control those their flow.
But I also went through the pain of strong_parameters, which breaks later lessons. Fortunately, Devise has a way to avoid these errors using their parameter sanitizer. You can read about it on the Devise documentation at https://github.com/plataformatec/devise. But here's what it looked like in action for me:
class ApplicationController < ActionController::Base
before_filter :configure_permitted_parameters, if: :devise_controller?
# Prevent CSRF attacks by raising an exception.
# For APIs, you may want to use :null_session instead.
protect_from_forgery with: :exception
def configure_permitted_parameters
devise_parameter_sanitizer.for(:sign_up) << [:email, :password, :password_confirmation, :remember_me, :first_name, :last_name, :profile_name]
end
end
Later in the lessons, you may also have some trouble with the status update parameter permissions, like I did. By default, the form accepts :name, but we name the parameter :user_id. My code at the end of the statuses controller looks like this:
def status_params
params.require(:status).permit(:user_id, :content)
end
I hope this helps!
Adam Kelm
29,082 PointsOops, I should also note that with the Devise parameter sanitizer, you would remove the attr_accessible from status.rb, since that's now being handled in the application controller.
Olly Whitman
12,919 PointsThanks Adam.
I get the idea behind moving them from the models to the controllers. But having read the documentation and trying your code snippet I'm still getting a NoMethodError for undefined method 'user'. I feel like I should know what's gone wrong but I can't see it.
Seriously considering starting from scratch in Rails 3.