The change in Rails 3.2.3 that will likely affect the most people is a new default setting in config/application.rb for newly generated applications. By default, Active Record is now configured to throw exceptions any time an attribute not included in attr_accessible is included in a mass assignment:
.
.
.
module SampleApp
class Application < Rails::Application
.
.
.
config.active_record.whitelist_attributes = true
.
.
.
end
end
The model generators have also been updated to include an attr_accessible line. Unfortunately, if you include all of the attributes in the call to rails generate at the command line, they will all be accessible by default, which kind of defeats the purpose. For example, if you type
$ rails generate model User name:string admin:boolean
class User < ActiveRecord::Base
attr_accessible :name, :admin
end
To see the effects of the new default, consider a User model with an admin attribute not included in the attr_accessible list:
class User < ActiveRecord::Base
attr_accessible :name, :email, :password, :password_confirmation
.
.
.
end
User.new(admin: true)
ActiveModel::MassAssignmentSecurity::Error
describe "accessible attributes" do
it "should not allow access to admin" do
expect do
User.new(admin: true)
end.should raise_error(ActiveModel::MassAssignmentSecurity::Error)
end
end
Remember that attr_accessible does NOT mean attributes that the application can change. It does NOT mean attributes that have automatic setters and getters. Even if an attribute isn't listed in attr_accessible, you can still write controller code to work with the attribute!
What attr_accessible means is "attributes that can be changed via mass-assignment, through #update_attributes or #create". These are the attributes that you are allowing users to change without supervision.
Keep attr_accessible minimal. Avoid the temptation to list every attribute your application will allow users to change. You can always write line-by-line setters, like:
u.role = params[:role] if role_safe?(params[:role])
* Do not include the authenticity token in forms where remote: true as ajax forms use the meta-tag value DHH
This doesn't really explain accurately what happened. It's not that the default behavior changed; rather a new option was actually introduced to allow you to easily do this if needed for fragment caching a remote form without making it cache a stale authenticity token (used to protect against CSRF attacks).
From the core mailing list:
Rails 3.2.3 also introduces a new option that allows you to control the behavior of remote forms when it comes to `authenticity_token` generation. If you want to fragment cache your forms, authenticity token will also get cached, which isn't acceptable. However, if you only use such forms with ajax, you can disable token generation, because it will be fetched from `meta` tag. Starting with 3.2.3, you have an option to stop generating `authenticity_token` in remote forms (ie. `:remote => true` is passed as an option), by setting `config.action_view.embed_authenticity_token_in_remote_forms = false`. Please note that this will break sending those forms with javascript disabled. If you choose to not generate the token in remote forms by default, you can still explicitly pass `:authenticity_token => true` when generating the form to bypass this setting. The option defaults to `true`, which means that existing apps are NOT affected.
After this conversation I became really interested :) My question - having no background in ruby or rails, should I just start from latest one? I.e. how compatible it with all code deployed already?
There are two main branches of Rails in use today: 2.3.x and 3.x . Many of the idioms involved in day to day coding are strikingly similar, but the internals are incompatible in many ways. As a workaday Rails programmer you'll typically spend 95% of your time working far away from the internals, so a solid background in MVP design and Ruby / object oriented programming gets you pretty far on both Rails 2 and 3. Their magic incantations for doing some things are different but they can be cheat sheeted or Googled at need.
In general, you would expect greenfield development to be on Rails 3 but a lot of the money in the ecosystem is still in Rails 2 apps.
I'll share my own story, having gone thru just this recently.
First I went thru Michael Hartl's tutorial back in Dec:
http://ruby.railstutorial.org/ruby-on-rails-tutorial-book
I believe it was in 3.0 at the time, now been updated to 3.2. No matter. I found a local business who needed something done but had never done more than Wordpress sites. I offerred my services pro-bono w/ a small equity share on the condition I could be mentored by a very sr. guy. At first they said "no, we want just one engineer solo on this". I said good luck with that and they got back to me two weeks later with a very sr. guy to give direction.
Beyond Hartl's excellent tutorial, which in printed form is probably 500 pages or so and will take maybe 40 hours of dedicated work, I highly recommend the Rails guides themselves. Just the getting started guide alone is chock full of info on getting a basic blogging platform together. In doing this project I have reviewed the majority of the Rails guides back and forth, read countless Stack Overflow threads, blog posts, rails casts, etc, and generally spend about 20-30 hours per week above and beyond my day job. The magic in this is that you will have to filter through a bunch of examples that may be several years old and are targeted at various versions of Rails, so you will sort of distill the differences in versions/idioms by osmosis in a way. If I had to take on a 2.3 code base at this point I doubt it would hinder me much.
Where do things stand now? Well, my current project is about to hit customer beta and my mentor has asked me to come along with him on another project for a client in NYC. Also I applied to a local early stage startup and despite having only 3 months under my belt they're considering bringing me on (they were looking for someone with 3+ years, but I learn quick and am very motivated :). If I get the job I'll likely take it (it's something I really believe in, potentially world changing stuff), say goodbye to the Windows enterprise world forever, and forgo doing further contract work for the time being as I won't likely have the time. My main interest now is getting good as quickly as possible. Long term, maybe this company will take off and I'll have the time of my life, maybe I'll strike out on my own startup, or maybe I too will pull $150/hr on contract. Who knows.
No need for that now, search for "rails examples" and you'll find the RailsApps project with useful example apps, all up to date (Rails 3.2) and kept current by a growing community of contributors: http://railsapps.github.com.
If you want to get started with Rails, I suggest reading the Rails Tutorial, which I just updated to use 3.2.3:
http://railstutorial.org/book?version=3.2
If you're going to be working on a Rails 3.0 project, you can use the first edition of the book instead:
http://railstutorial.org/book?version=3.0
Screencasts for the 3.0 version are available at http://railstutorial.org/screencasts, and I'm planning to start on the 3.2 screencasts later today.
If you plan on running with a project that's already going that is going to slow down your learning curve. I would recommend doing things from scratch. It's important you truly understand what is happening then just a copy/paste action.