public
Description: a better mass assignment method for ActiveRecord that allows contextual whitelists of assignable attributes
Homepage: http://codelevy.com
Clone URL: git://github.com/cainlevy/mass_assignment.git
name age message
file MIT-LICENSE Mon May 25 16:16:59 -0700 2009 simple [cainlevy]
file README.textile Tue May 26 17:26:57 -0700 2009 add policies to the readme [cainlevy]
file Rakefile Mon May 25 16:16:59 -0700 2009 simple [cainlevy]
file init.rb Mon May 25 16:16:59 -0700 2009 simple [cainlevy]
directory lib/ Wed May 27 14:13:14 -0700 2009 gracefully handle nil attribute sets [cainlevy]
directory test/ Wed May 27 14:13:14 -0700 2009 gracefully handle nil attribute sets [cainlevy]
README.textile

MassAssignment

Copyright © 2009 Lance Ivy, released under the MIT license

From initial discussion at http://groups.google.com/group/rubyonrails-core/browse_thread/thread/3b6818496d0d07f1

What It Is

A robust mass assignment method with a small and obvious syntax.

The normal mass assignment protection comes from attr_protected and attr_accessible. There are a few problems with this approach:

  • Often never implemented, leaving a wide-open system. And once implemented, easy to forget when adding new attributes, leading to bugs (in an attr_accessible system) or security holes (in an attr_protected system).
  • Restricts coding syntax. You can’t easily use update_attributes() or attributes= because your whitelist/blacklist gets in your own way.
  • Not contextual. The list of allowed attributes can’t change to accomodate different user permissions or situations.

This plugin’s solution is to let you specify an obvious list of allowed attributes when you mass assign attributes.

  • The list of allowed attributes is in your controller at calltime, so it’s easier to remember and update (it’s not a hidden, magical system).
  • The list of allowed attributes is optional, so it doesn’t get in your way.
  • Your controller can easily enforce permissions by evaluating the current user (Admin Controller) or the current situation (creates vs updates).

And as a bonus, permission plugins have a much easier time of things. The list of allowed attributes may be pulled from a permissions table without any awkward User.current class or thread variables.

For those who would still like attr_protected- and attr_accessible-like functionality, this plugin offers mass assignment policies. You may choose to a default mass assignment protection as open or closed as you like using familiar :only/:except syntax. But you may also specify regular expressions such as /_id$/ to reject all id fields by default, and since these policies inherit, you may set them globally on ActiveRecord::Base. See the examples below.

Example

Let’s take a very plausible situation where you would want three separate lists of allowed attributes. You have users that sign up to your application. But after they have signed up, they may not change their username. Admins, however, may manually change a username as needed.


  class UsersController < ApplicationController
    def create
      @user = User.new
      # during signup a user may pick a username
      @user.assign(params[:user], [:username, :email, :password, :password_confirmation])
      @user.save!
      ...
    end

    def update
      @user = User.find(params[:id])
      # username is no longer accepted later
      @user.assign(params[:user], [:email, :password, :password_confirmation])
      @user.save!
      ...
    end
  end

  class Admin::UsersController < ApplicationController
    before_filter :admin_required

    def update
      @user = User.find(params[:id])
      # admins, on the other hand, may change the username as needed, but may not set passwords
      @user.assign(:params[:user], [:username, :email])
      @user.save!
      ...
    end
  end

If you don’t always want to set attribute lists, you may use the mass_assignment_policy API to configure defaults whitelists or blacklists.


  class User < ActiveRecord::Base
    # The boring usage. You may as well specify attributes at calltime.    
    mass_assignment_policy :only => [:email, :username]
    
    # More interesting. No id fields!
    mass_assignment_policy :except => /_id$/
  end
  
  # Hardcore. Disables mass assignment globally unless overridden!
  ActiveRecord::Base.mass_assignment_policy :except => :all

Note that mass_assignment_policy only applies to usage of methods supplied in this plugin.

Feedback

I can think of a couple alternate implementations for this API. Consider:

@user.assign(params[:user], [:username, :email])

vs

@user.assign(params[:user], :only => [:username, :email]) @user.assign(params[:user], :except => [:admin])

I personally prefer the former because I think that blacklists are inherently less safe than whitelists, with no compensating advantage. But I’d love to hear some other use cases and get feedback on this! Fork this repo and send pull requests or just contact me (github.com/cainlevy). Let’s talk.