Formatted the README to my liking and swapped out allow_assignment for the new allow_params API. Example of single param usage

Signed-off-by: Gareth Townsend <[email protected]>

Author: benschwarz

README.markdown

@@ -1,5 +1,4 @@
-Bouncer
-=======
+# Bouncer
 
 Your rails app is like a club. Everyone wants in. Most users are fine, but every now and again someone wants to cause trouble.
 
@@ -8,73 +7,68 @@ You need a bouncer to keep the riff raff out.
 Bouncer allows you to filter the params passed into your controller so that you can safely manage mass assignment at the controller level.
 
 
-Example
-=======
+## Example
 
 Take a user model with the following attributes: login, password, admin.
 
 admin is a boolean that signifies whether the user has the ability to perform admin tasks.
 
 You probably use the following code throughout your application in controllers. 
 
-<pre>
-<code>
-  @user = User.new(params[:user])
-</code>
-</pre>
+    @user = User.new(params[:user])
+
 
 This code is problematic. Should a user decide to fiddle with your parameters and pass in admin=true you could have a bit of a problem on your hands.
 
 You need a bouncer with a door list.
 
-<pre>
-<code>
-class UsersController < ApplicationController
-  allow_assignment :user => [ :login, :password ]
-end
-</code>
-</pre>
+    class UsersController < ApplicationController
+      allow_params :user => [ :login, :password ]
+    end
 
-Now you can safely use <code> User.new(params[:user])</code> in your controller to mass assign only the attributes you've said are safe.
+Now you can safely use `User.new(params[:user])` in your controller to mass assign only the attributes you've said are safe.
 
-You should use allow_assignment in every controller within your application. By default bouncer will strip everything from the params hash that isn't required by rails to operate.
+You should use allow_params in every controller within your application. By default bouncer will strip everything from the params hash that isn't required by rails to operate.
 
-Why Not Use attr_accessible?
-==========================
+# Why Not Use attr_accessible?
 
-attr_accessible is great. But it's handled at the model level.
+`attr_accessible` is great. But it's handled at the model level.
 
 You might want to allow assignment of the admin attribute from an admin specific user interface.
 
 You end up with code like this:
 
-<pre>
-<code>
-class AdminUsersController < ApplicationController
+    class AdminUsersController < ApplicationController
 
-  ...
-  @user = User.new(params[:user])
-  @user.admin = params[:user][:admin]
-  ...
+      ...
+      @user = User.new(params[:user])
+      @user.admin = params[:user][:admin]
+      ...
 
-end
-</code>
-</pre>
+    end
+
 
 The following is much nicer:
 
-<pre>
-<code>
-class UsersController < ApplicationController
-  allow_assignment :user => [ :login, :password ]
-end
+    class UsersController < ApplicationController
+      allow_params :user => [ :login, :password ]
+    end
+
+    class AdminUsersController < ApplicationController
+      allow_params :user => [ :login, :password, :admin ]
+    end
+    
+You can also post single params like `:id` for things like activation tokens and pagination keys.
+
+    class ActivationsController < ApplicationController
+      allow_params :token
+      
+      def create
+        @user = User.find_by_activation_token(params[:token])
+      end
+    end
 
-class AdminUsersController < ApplicationController
-  allow_assignment :user => [ :login, :password, :admin ]
-end
-</code>
-</pre>
 
 Copyright (c) 2009 Gareth Townsend, released under the MIT license
 
-Thanks to Josh Bassett for helping nut out <code>self.request.env['rack.routing_args'].keys</code> and other refactorings.
+Thanks to Josh Bassett for helping nut out `self.request.env['rack.routing_args'].keys` and other refactorings.