title: Rails Strong Parameters ActiveModel::ForbiddenAttributesError NOT showing up
body: <p>I am using Rails 4.0.2, Ruby 2.0.0p353</p>
  
  <p>I am trying to use strong parameters in my Rails project but I can't get the ActiveModel::ForbiddenAttributesError to appear.</p>
  
  <p>If there are params that are <strong>not permitted</strong>, those params will be set to nil or 0, but I thought that the error ActiveModel::ForbiddenAttributesError should appear. So as a result, params that are not permitted by the strong parameters will be passed into my User model as nil or 0 and this is a problem for me.</p>
  
  <p>Below is the following for my <strong>UsersController</strong>:</p>
  
  <pre><code>class UsersController &lt; ApplicationController
  
    def new
      @user = User.new
    end
  
    def create
      @user = User.new(user_params)
  
      if @user.save
        sign_in @user
        flash[:notice] = "Welcome to the league!"
        redirect_to root_url
      else
        render 'new'
      end
    end
  
    private
      def user_params
        params.require(:user).permit(:first_name, :last_name, :alias, 
                                     :email, :password, :password_confirmation)
      end
  end
  </code></pre>
  
  <p>Here is the User sign-up form using, simple_form 3.0.1, <strong>new.html.erb</strong>:</p>
  
  <pre><code>&lt;%= simple_form_for(@user) do |f| %&gt;
  
    &lt;h1&gt;Sign Up&lt;/h1&gt;
  
    &lt;%= f.input :first_name %&gt;
    &lt;%= f.input :last_name %&gt;
    &lt;%= f.input :alias %&gt;
    &lt;%= f.input :email %&gt;
    &lt;%= f.input :password %&gt;
    &lt;%= f.input :password_confirmation %&gt;
    &lt;%= f.button :submit, class: "btn-lg btn-primary" %&gt;
  &lt;% end %&gt;
  </code></pre>
  
  <p>And here are the validations for my User model <strong>user.rb</strong>:</p>
  
  <pre><code>class User &lt; ActiveRecord::Base
  
    ...
  
    # Validations
    validates :first_name, presence: true, length: { maximum: MAX_LENGTH_FIRST_NAME }
    validates :last_name, presence: true, length: { maximum: MAX_LENGTH_LAST_NAME }
    validates :alias, presence: true
    validates :email, presence: true,
                      format: { with: VALID_EMAIL_REGEX },
                      uniqueness: { case_sensitive: false }
    has_secure_password
    validates :password, length: { minimum: MIN_LENGTH_PASSWORD }
  
    ...
  
  end
  </code></pre>
  
  <p>Now let's say that I <strong>remove</strong> :alias from user_params like so:</p>
  
  <pre><code> private
      def user_params
        params.require(:user).permit(:first_name, :last_name, 
                                     :email, :password, :password_confirmation)
      end
  </code></pre>
  
  <p>From my understanding, if there is an :alias hash (or any other hash) in my :user params, then I should get the ActiveModel::ForbiddenAttributesError to appear.</p>
  
  <p>So what I have tried is removing :alias from from user_params and <strong>keeping</strong> alias on the user sign up form so that I can have :alias in user_params to raise the error. In order to keep it on my form and be able to submit it, I had to comment out my alias validation in my model to like so:</p>
  
  <pre><code> # validates :alias, presence: true
  </code></pre>
  
  <p>But when I create a new user with all of the fields, including alias, <strong>no error appears</strong>. Instead, I create a new user in the database with all of the information, but the alias attribute is <strong>nil</strong> no matter what I entered on the form.</p>
  
  <p>If anyone could tell me how to have <strong>unpermitted</strong> params raise an exception, please let me know.</p>
  
  <p>Thanks in advance.</p>
  
  <p>*<strong><em>EDIT</em>*</strong></p>
  
  <p>The reason I posted this was actually for an update_attributes(). </p>
  
  <p>My issue was that I was trying to update only 3 (out of 5) of a user's attributes. I tried to make strong parameters to make sure that only those 3 attributes were being updated and nothing else, but I guess that is the wrong way to do it.</p>
  
  <p>Thanks again to Brian for the clarification on the error and how it is actually raised.</p>