From 0087ef9665e82eec357331ebce759fb1298286a7 Mon Sep 17 00:00:00 2001
From: Sebastian Martinez <sebastian@wyeworks.com>
Date: Sat, 21 May 2011 16:51:05 -0300
Subject: Remove extra white spaces.

---
 railties/guides/source/security.textile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'railties/guides/source/security.textile')

diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile
index e0ccc7a6e6..1a1339137c 100644
--- a/railties/guides/source/security.textile
+++ b/railties/guides/source/security.textile
@@ -386,7 +386,7 @@ params[:user] # => {:name => “ow3ned”, :admin => true}
 
 So if you create a new user using mass-assignment, it may be too easy to become an administrator.
 
-Note that this vulnerability is not restricted to database columns.  Any setter method, unless explicitly protected, is accessible via the <tt>attributes=</tt> method. In fact, this vulnerability is extended even further with the introduction of nested mass assignment (and nested object forms) in Rails 2.3+. The +accepts_nested_attributes_for+ declaration provides us the ability to extend mass assignment to model associations (+has_many+, +has_one+, +has_and_belongs_to_many+). For example:
+Note that this vulnerability is not restricted to database columns. Any setter method, unless explicitly protected, is accessible via the <tt>attributes=</tt> method. In fact, this vulnerability is extended even further with the introduction of nested mass assignment (and nested object forms) in Rails 2.3+. The +accepts_nested_attributes_for+ declaration provides us the ability to extend mass assignment to model associations (+has_many+, +has_one+, +has_and_belongs_to_many+). For example:
 
 <ruby>
   class Person < ActiveRecord::Base
@@ -469,7 +469,7 @@ A more paranoid technique to protect your whole project would be to enforce that
 config.active_record.whitelist_attributes = true
 </ruby>
 
-This will create an empty whitelist of attributes available for mass-assignment for all models in your app. As such, your models will need to explicitly whitelist or blacklist accessible parameters by using an +attr_accessible+ or +attr_protected+ declaration.  This technique is best applied at the start of a new project. However, for an existing project with a thorough set of functional tests, it should be straightforward and relatively quick to use this application config option; run your tests, and expose each attribute (via +attr_accessible+ or +attr_protected+) as dictated by your failing tests.
+This will create an empty whitelist of attributes available for mass-assignment for all models in your app. As such, your models will need to explicitly whitelist or blacklist accessible parameters by using an +attr_accessible+ or +attr_protected+ declaration. This technique is best applied at the start of a new project. However, for an existing project with a thorough set of functional tests, it should be straightforward and relatively quick to use this application config option; run your tests, and expose each attribute (via +attr_accessible+ or +attr_protected+) as dictated by your failing tests.
 
 h3. User Management
 
-- 
cgit v1.2.3

