By popular (cue laughter) demand, I have added whitelisting to the popular (cue hysterical laughter) param_protected plugin. It is done via the param_accessible method.
I have also added support to properly handle array params.
For more details (i.e. documentation), please see the README file.
It is a Ruby on Rails plugin that provides param_protected and param_accessible methods on controllers analogous to the attr_protected and attr_accessible methods for models.
It is a very simple -- all it does it filter out specified parameters from a request.
Good question... you can ready about why attr_protected sucks here, or you can just read my following little rant...
What's the goal of attr_protected? To protect us from user input, not from ourselves. When I used attr_protected, I had to refactor tons of code in models, controllers and tests (that already worked well) to not use the mass attribute setters.
Was this massive code refactoring really worth the protection from the very few places were I do something like:
User.new(params[:user])
or
User.update_attributes(params[:user])
Truth of the matter, I was hardly ever passing params (or a subset thereof) to a mass attribute setter. So no, it wasn't worth the massive refactoring job.
git clone git://github.com/cjbottaro/param_protected.git vendor/plugins/param_protected
param_protected :user_id
end
param_accessible :account_id
end
param_protected is used to blacklist and param_accessible is used to whitelist.
You can give it an array of param names to filter:
param_protected [:user_id, :some_other_param]
param_protected and param_accessible are both just before filters, so the usual :only and :except arguments can be used:
param_protected :user_id, :only => :some_action
param_protected :user_id, :only => [:some_action, :another_action]
param_protected :user_id, :except => :some_action
param_protected :user_id, :except => [:some_action, :another_action]
You can protect nested params also (removes params[:user][:user_id]):
param_protected 'user/user_id'
param_protected is aware of array params and handles them properly.
Because param_protected is really a before filter (uses prepend_before_filter), you must take special care to ensure that it runs before any of your other before filters!! If it is not, some of your before filters might have access to some params they shouldn't.
rake test should work (from the plugin's root dir), though it's far from comprehensive.
Managing migration version numbers in Rails among multiple developers using the same database is a pain in the ass. You know the drill, you svn up, create a migration, try to run db:migrate but low and behold, the db version is already 10 versions above your migration's.
This plugin offers a simple solution: create and manage a "history" table that records which migrations have and have not been run and modify rake db:migrate to behave accordingly.
For documentation, installation and usage instructions, please see the migration_izzle github page (scroll down).
