

Rails 3.2.3 has been released - timewasted
http://weblog.rubyonrails.org/2012/3/30/ann-rails-3-2-3-has-been-released/

======
mhartl
_Note_ : For the purposes of this discussion, "accessible" means "accessible
via mass assignment". See <http://news.ycombinator.com/item?id=3781317>.

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
    

For more details, see the latest version of the _Ruby on Rails Tutorial_
(<http://railstutorial.org/book?version=3.2>).

~~~
tptacek
Broken record:

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.

~~~
Empact
Yep, and the new strong_parameters library from core team supports this and is
a taste of things to come: moving towards consistently controller-based
access-control. <http://weblog.rubyonrails.org/2012/3/21/strong-parameters/>

~~~
tptacek
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.

------
JangoSteve
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._

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

~~~
patio11
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.

~~~
mhartl
In this vein, there's actually still a Rails 2.3 version of the _Rails
Tutorial_ online:

<http://railstutorial.org/book?version=2.3>

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

