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
(Exactly what this means is explained below.)
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
you'll get
class User < ActiveRecord::Base
attr_accessible :name, :admin
end
which probably isn't what you want: chances are that the admin attribute shouldn't be accessible. To prevent security holes, I therefore strongly recommend writing explicit tests for all inaccessible attributes (see below).
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
With the new default configuration, code like
User.new(admin: true)
will raise an
ActiveModel::MassAssignmentSecurity::Error
exception. You can test for this (in RSpec) as follows:
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])
If you don't keep your attr_accessible statements minimal, you can end up with mass-assignment problems even when you have whitelisting enabled.
I am not, by the way, sold on this particular ideology about models and controllers. The controller-based pattern has stuff to recommend it, as does the model-based pattern. I think most apps are going to end up wanting to do both.
One of the other interesting changes in this release from my perspective:
* 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.
friend of mine recently asked "do you do rails?", I answered something like "nope, going to learn it only if it will be paid well". "well, you can get $150/hr on the project I am working on"...
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?
You'll catch a bit of unease with that motivation from some quarters, for what it is worth, but I generally applaud people making microecon 101 work for them.
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.
Rails 3.2.3 is compatible with Rails 3.1 and later versions. The main difference is a change in the default security settings (made in the wake of the recent GitHub mass assignment vulnerability—and, IMHO, long overdue).
If you want to get started with Rails, I suggest reading the Rails Tutorial, which I just updated to use 3.2.3:
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.
> you will have to filter through a bunch of examples that may be several years old
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.
Michael Hartl's guide is excellent and can back that up as as a great starting point.
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.
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:
(Exactly what this means is explained below.)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
you'll get which probably isn't what you want: chances are that the admin attribute shouldn't be accessible. To prevent security holes, I therefore strongly recommend writing explicit tests for all inaccessible attributes (see below).To see the effects of the new default, consider a User model with an admin attribute not included in the attr_accessible list:
With the new default configuration, code like will raise an exception. You can test for this (in RSpec) as follows: For more details, see the latest version of the Ruby on Rails Tutorial (http://railstutorial.org/book?version=3.2).