Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate strong_parameters in Rails 4 #7251

Merged
merged 23 commits into from Sep 18, 2012

Conversation

Projects
None yet
@guilleiguaran
Copy link
Member

guilleiguaran commented Aug 3, 2012

This integrate strong_parameters plugin in Rails core and remove attr_accessible/attr_protected.

@guilleiguaran

This comment has been minimized.

Copy link
Member Author

guilleiguaran commented Aug 3, 2012

@@ -0,0 +1,14 @@
module ActiveModel
class ForbiddenAttributes < StandardError

This comment has been minimized.

@rafaelfranca

rafaelfranca Aug 3, 2012

Member

Is not better call this exception ForbiddenAttrbibutesError or something like this?

This comment has been minimized.

@guilleiguaran

guilleiguaran Aug 3, 2012

Author Member

Agree, sounds better, we should also change it in the gem to keep both synced

This comment has been minimized.

@guilleiguaran

guilleiguaran Aug 13, 2012

Author Member

Done

Note to myself: This change is pending on gem

# params.require(:person).permit(:name, :age)
# Also, you can specialize this method with per-user checking of permissible attributes.
def <%= "#{singular_table_name}_params" %>
params.require(<%= ":#{singular_table_name}" %>).permit(<%= attributes.map {|a| ":#{a.name}" }.sort.join(', ') %>)

This comment has been minimized.

@rafaelfranca

rafaelfranca Aug 3, 2012

Member

If the attributes are empty do we'll generate: params.require(:user).permit()?

This comment has been minimized.

@guilleiguaran

guilleiguaran Aug 3, 2012

Author Member

You're right, what do you think we should do in this case? generate just params.require(:user) ?

This comment has been minimized.

@rafaelfranca

rafaelfranca Aug 3, 2012

Member

I think so. This means that if the user doesn't pass the attributes we still generate a secure controller since the parameters will not be permitted.

This comment has been minimized.

@josevalim

josevalim Aug 4, 2012

Contributor

I would leave it as params.require(:user).permit(), otherwise the default will be to allow everything from then on.

This comment has been minimized.

@rafaelfranca

rafaelfranca Aug 4, 2012

Member

I think that without permit it will raise an exception

Rafael Mendonça França
On Aug 4, 2012 7:53 AM, "José Valim" <
reply@reply.github.com>
wrote:

@@ -85,5 +85,14 @@ def destroy
format.json { head :no_content }
end
end
+

  • private
  • Use this method to whitelist the permissible parameters. Example:

  • params.require(:person).permit(:name, :age)

  • Also, you can specialize this method with per-user checking of

permissible attributes.

  • def <%= "#{singular_table_name}_params" %>
  •  params.require(<%= ":#{singular_table_name}" %>).permit(<%=
    
    attributes.map {|a| ":#{a.name}" }.sort.join(', ') %>)

I would leave it as params.require(:user).permit(), otherwise the
default will be to allow everything from then on.


Reply to this email directly or view it on GitHub:
https://github.com/rails/rails/pull/7251/files#r1307224

This comment has been minimized.

@guilleiguaran

guilleiguaran Aug 25, 2012

Author Member

params.require(:user) should be fine since it shouldn't allow everything (we aren't adding nothing to whitelist)

@rafaelfranca

This comment has been minimized.

Copy link
Member

rafaelfranca commented Aug 3, 2012

I think we will need a hidden option to disable strong_parameters that should be set by the attr_accessible plugin.

Also guides and docs should be updated/written.

@josevalim

This comment has been minimized.

Copy link
Contributor

josevalim commented Aug 4, 2012

Thanks @guilleiguaran for the PR and @rafaelfranca for the review. I want to take a look at this as well, but I will be able to do it just later this week!

@spastorino

This comment has been minimized.

Copy link
Member

spastorino commented Aug 4, 2012

Agree with @rafaelfranca about disabling strong_parameters, should be a hidden option to do that to allow attr_accessible plugin to work without strong_parameters.

@spastorino

This comment has been minimized.

Copy link
Member

spastorino commented Aug 4, 2012

What if people attr_accessible or attr_protected in 4.0 without the plugin?. Couldn't we leave those methods and raise an error saying "Add the plugin to the Gemfile or move to strong_parameters. @josevalim what do you think?

@rafaelfranca

This comment has been minimized.

Copy link
Member

rafaelfranca commented Aug 4, 2012

Good point. 👍 for this

Rafael Mendonça França
On Aug 4, 2012 11:15 AM, "Santiago Pastorino" <
reply@reply.github.com>
wrote:

What if people attr_accessible or attr_protected in 4.0 without the
plugin?. Couldn't we leave those methods and raise an error saying "Add the
plugin to the Gemfile or move to strong_parameters. @josevalim what do you
think?


Reply to this email directly or view it on GitHub:
#7251 (comment)

@spastorino

This comment has been minimized.

Copy link
Member

spastorino commented Aug 4, 2012

I'd also squash some commits, like bfac9c4 25c2fe8 and 678137e in the future this will make much easier to understand why the code was added

@spastorino

This comment has been minimized.

Copy link
Member

spastorino commented Aug 4, 2012

Besides from all that is looking great ❤️ ❤️ ❤️

@guilleiguaran

This comment has been minimized.

Copy link
Member Author

guilleiguaran commented Aug 7, 2012

@spastorino @josevalim @rafaelfranca thanks for you feedback guys, I'm starting to change the code with your suggestions

@homakov

This comment has been minimized.

Copy link
Contributor

homakov commented Aug 13, 2012

❤️

@kirs

This comment has been minimized.

Copy link
Member

kirs commented Aug 13, 2012

Could you explain how does the strong_parameters work or maybe write some docs?

@dmathieu

This comment has been minimized.

Copy link
Contributor

dmathieu commented Aug 13, 2012

@kirs: there is documentation in the strong parameters gem.
But indeed, an update of the official documentation will be necessary.

end
end

class Parameters < ActiveSupport::HashWithIndifferentAccess

This comment has been minimized.

@pixeltrix

pixeltrix Aug 25, 2012

Member

Would it be better if ActionController::Parameters wrapped a Hash rather than inherited from ActiveSupport::HashWithIndifferentAccess? For example CookieJar used to inherit from Hash but was changed in 0ca69ca. @tenderlove, what do you think?

This comment has been minimized.

@rafaelfranca

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 9, 2012

Author Member

@rafaelfranca can you work on this, I'm no having much luck with this and @spastorino won't have time to check it on the next weeks

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 9, 2012

Member

Even though my opinion is to do so, I think the final decision was to not change.

This comment has been minimized.

@rafaelfranca

rafaelfranca Sep 9, 2012

Member

I remember some discussion about this one but I didn't read yet. I'll try to read now.

This comment has been minimized.

@kuraga

kuraga Sep 9, 2012

@rafaelfranca it'll be great you post a link :)

This comment has been minimized.

@rafaelfranca

rafaelfranca Sep 10, 2012

Member

@kuraga I can't. It is a private discussion.

@guilleiguaran

This comment has been minimized.

Copy link
Member Author

guilleiguaran commented Sep 6, 2012

I've extracted ActiveModel::MassAssignmentSecurity and ActiveRecord/AC::ParamsWrapper integration to the protected_attributes plugin:

https://github.com/rails/protected_attributes

Right now everything is working fine except integration with AR deprecated finders (related tests), can someone help me fixing it?

/cc @jonleighton @tenderlove

@guilleiguaran

This comment has been minimized.

Copy link
Member Author

guilleiguaran commented Sep 6, 2012

The plugin is ready and all tests passing, this is ready now

/cc @dhh

require 'active_support/rescuable'

module ActionController
class ParameterMissing < IndexError

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

Since we're dealing with parameters that emulate a hash, it seems to be more appropriate to use KeyError, not? (I know it's a subclass, just thought it might be a better error to inherit from)

>> [].fetch 1
IndexError: index 1 outside of array bounds: 0...0

>> {}.fetch :a
KeyError: key not found: :a

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Agree 100% on this, I will change it

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Done


included do
config_accessor :permit_all_parameters
self.permit_all_parameters ||= false

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

I don't see this being used anywhere, since it's apparently always setting Parameters.permit_all_parameters. Is this supposed to be a per-controller config? Also, there's probably no need for ||=.

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Isn't a per-controller config, is a global setting for all controllers. This was added to be used in protected_attributes plugin and it's used just to bypass strong_parameters protection marking everything as permitted.

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 10, 2012

Member

Yeah, I got it. But I didn't see the controller config permit_all_parameters being used anywhere, even though the config will propagate to the config, it is not propagated to the Parameters object, which seems to aways do self.class.permit_all_parameters. Did I miss anything?

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Got it, I'm setting AC::Parameters config directly in https://github.com/rails/rails/pull/7251/files#L4R23, so this isn't really needed here, right?

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Removing this I get a failure in railties:

  1) Failure:
test_0042_config.action_controller.permit_all_parameters = true(ApplicationTests::ConfigurationTest) [test/application/configuration_test.rb:582]:
--- expected
+++ actual
@@ -1 +1,27 @@
-"permitted"
+"<!DOCTYPE html>
+<html>
+<head>
+  <title>We're sorry, but something went wrong (500)</title>
+  <style>
+    body { background-color: #fff; color: #666; text-align: center; font-family: arial, sans-serif; }
+    div.dialog {
+      width: 25em;
+      padding: 0 4em;
+      margin: 4em auto 0 auto;
+      border: 1px solid #ccc;
+      border-right-color: #999;
+      border-bottom-color: #999;
+    }
+    h1 { font-size: 100%; color: #f00; line-height: 1.5em; }
+  </style>
+</head>
+
+<body>
+  <!-- This file lives in public/500.html -->
+  <div class=\"dialog\">
+    <h1>We're sorry, but something went wrong.</h1>
+  </div>
+  <p>If you are the application owner check the logs for more information.</p>
+</body>
+</html>
+"

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 10, 2012

Member

I think it's the test that you added, that's trying to also set the option to AC::Base. If you remove it, the option will not exist, which will raise an invalid option error.

Is it possible to use delete or something like that with the parameters initializer? Then that option wouldn't exist down the chain.

self.permit_all_parameters ||= false

rescue_from(ActionController::ParameterMissing) do |parameter_missing_exception|
render :text => "Required parameter missing: #{parameter_missing_exception.param}", :status => :bad_request

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

Can use 1.9 hash style.

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Changed

end

def require(key)
self[key].presence || raise(ActionController::ParameterMissing.new(key))

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

I think there's no need to fully qualify with ActionController.

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Changed

super.tap do |duplicate|
duplicate.instance_variable_set :@permitted, @permitted
end
end

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

Shouldn't we override initialize_dup (or copy) instead? More on @jonleighton's post

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

HashWithIndifferentAccess is overriding #dup and it doesn't call to super or initialize_dup never, so if we override initialize_dup or initialize_copy here it won't be called never

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 10, 2012

Member

=( Ok, it's something we can fix there and here later.


value = self.class.new(value) if !value.respond_to?(:permit)

value.permit(*Array.wrap(filter[key]))

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

There's probably no need for Array.wrap.

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

got a failure removing it:

1) Failure:
test_0004_nested array with strings that should be hashes(NestedParametersTest) [/Users/guille/code/rails/actionpack/test/controller/parameters/nested_parameters_test.rb:68]:
Expected nil (NilClass) to respond to #empty?.

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 10, 2012

Member

Just removing or changing to Array()?

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

I had same results removing and changing to Array()

This comment has been minimized.

@rafaelfranca

rafaelfranca Sep 10, 2012

Member

Weird I didn't see any case where Kernel#Array can return nil.

>> Array(nil)
=> []
>> Array([])
=> []
>> Array(1)
=> [1]
>> Array(raise 'foo')
RuntimeError: foo
    from (irb):4
    from /Users/rafaelmfranca/.rbenv/versions/1.9.3/bin/irb:12:in `<main>'
>> Array({})
=> []

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Here we are wrapping a Hash:

>> Array.wrap({key: "value"})
=> [{:key=>"value"}]
>> Array({key: "value"})
=> [[:key, "value"]]
>> Array({})
=> []
>> Array.wrap({})
=> [{}]

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 10, 2012

Member

In this particular case, isn't Array.wrap a defensive thing? What will the difference be over:

value.permit(*Array.wrap(filter[key]))
# vs
value.permit(filter[key])

Do we expect it to be nil or something else?

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 20, 2012

Author Member

@carlosantoniodasilva sorry, just saw your last reply now, you're right this is defensive, feel free to improve it in master branch 😄

This comment has been minimized.

@rafaelfranca

rafaelfranca Sep 20, 2012

Member

This is not just defensive. Sometimes filter[key] return just an element and the splat operator would not work.

private

# Use this method to whitelist the permissible parameters. Example:
# params.require(:person).permit(:name, :age)

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

I think the Example: could be in the same line.

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Done

params.require(<%= ":#{singular_table_name}" %>).permit(<%= attributes.map {|a| ":#{a.name}" }.sort.join(', ') %>)
<%- else -%>
params[<%= ":#{singular_table_name}" %>]
<%- end -%>

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

Can we invert this unless..else to if..else please?

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Done

[]
end
end
def sanitize_for_mass_assignment(attributes, options = {})

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

Space before the method.

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Done

attributes.reject! do |key, value|
self.class.attributes_forbidden_by_default.include?(key)
end
if attributes.respond_to?(:permitted?) && !attributes.permitted?

This comment has been minimized.

@carlosantoniodasilva

carlosantoniodasilva Sep 8, 2012

Member

Space before the if.

This comment has been minimized.

@guilleiguaran

guilleiguaran Sep 10, 2012

Author Member

Done

guilleiguaran added some commits Jul 18, 2012

Change AMo::ForbiddenAttributesProtection tests to use a subclass of …
…Hash instead of monkey patch permitted? method in regular hashes

dhh added a commit that referenced this pull request Sep 18, 2012

Merge pull request #7251 from rails/integrate-strong_parameters
Integrate strong_parameters in Rails 4

@dhh dhh merged commit c49d959 into master Sep 18, 2012

1 check passed

default The Travis build passed
Details
@dapi

This comment has been minimized.

Copy link

dapi commented Sep 24, 2012

Strong Prameters does not solve the problem of checking parameters in Rails. The problem is model-based validation.

Require or not require, permit or not permit, validate and how to validate - these are questions of the Form, not of a model and not of a controller.

Model-based validation must be like SQL constraints - simple, basic and unconditional. It's about solidity of data, it's about consistency, not roles or permissions.

And params are form-specific, not of controller. They can be used with different models, presenters and controllers.

One form can require :password, another one require :email, another one require :full_name and permit to another field.

Another problem with StrongParameters - they ara introduce duplication of responsibilities:

params.require(:user) # in controller

and

validates :user, :presence => true # model

What is difference between these approaches?

Resolution

Checking parameters (validation, requirements etc) must be extracted to the dedicated class.

@steveklabnik

This comment has been minimized.

Copy link
Member

steveklabnik commented Sep 24, 2012

Basically nobody on the rails team but me is obsessive enough to read everything in comments on commits. The official place to talk about stuff like this is the rails-core list.

@dhh

This comment has been minimized.

Copy link
Member

dhh commented Sep 24, 2012

I have many forms pointing to the same controllers. Desktop and mobile web views, APIs, etc. This verification also cannot be trusted to the view as you don't want to tamper with it.

I wouldn't bother with the validates :user, :presence check if you feel like you're duplicating yourself.

On Sep 24, 2012, at 10:25 AM, Danil Pismenny wrote:

Strong Prameters does not solve the problem of checking parameters in Rails. The problem is model-based validation.

Require or not require, permit or not permit, validate and how to validate - these are questions of the Form, not of a model and not of a controller.

Model-based validation must be like SQL constraints - simple, basic and unconditional. It's about solidity of data, it's about consistency, not roles or permissions.

And params are form-specific, not of controller. They can be used with different models, presenters and controllers.

One form can require :password, another one require :email, another one require :full_name and permit to another field.

Another problem with StrongParameters - they ara introduce duplication of responsibilities:

params.require(:user) # in controller

and

validates :user, :presence => true # model

What is difference between these approaches?

Resolution

Checking parameters (validation, requirements etc) must be extracted to the dedicated class.


Reply to this email directly or view it on GitHub.

David Heinemeier Hansson

@dapi

This comment has been minimized.

Copy link

dapi commented Sep 24, 2012

I'm talking not about view's.

In real life Forms contains two parts.
First is a view (it's Formastic or so)
Second - some server-side object that requires and validates parameters (it
is missed in Rails)

The list of required and permitted parameters is linked to forms, not to
actions of controllers and not to models.

Example.

  1. RegistrationForm:
    = f.input :login
    = f.input :password
    = f.input :password_confirm

  2. Profile update form:
    = f.input :login
    = f.input :email
    = f.input :name

  3. Form for update password:
    = f.input :password
    = f.input :password_confirm

  4. Form of editing users for admins:
    = f.input :login
    = ..etc all parameters

  5. Form for second-lever users:
    = f.input :login
    = f.input :specific_field

In every form specific list of fields, specific list of required and
permitted fields.

In controller we must have something like this:

RegistrationFormVlidator.new.validate params
ProfileFormValidator.new.validate params
PasswordFormVlidator.new.validate params
etc

Every FormValidator requires and permits and also validates parameters in
their own way.

Yes we can have default UserFormValidator or specific role of current_user
to this FormValidator.

The key question is validation, not just requires and permits. And
extraction of these functions from controller to a separate class.

On Mon, Sep 24, 2012 at 8:14 PM, David Heinemeier Hansson <
notifications@github.com> wrote:

I have many forms pointing to the same controllers. Desktop and mobile web
views, APIs, etc. This verification also cannot be trusted to the view as
you don't want to tamper with it.

I wouldn't bother with the validates :user, :presence check if you feel
like you're duplicating yourself.

On Sep 24, 2012, at 10:25 AM, Danil Pismenny wrote:

Strong Prameters does not solve the problem of checking parameters in
Rails. The problem is model-based validation.

Require or not require, permit or not permit, validate and how to
validate - these are questions of the Form, not of a model and not of a
controller.

Model-based validation must be like SQL constraints - simple, basic and
unconditional. It's about solidity of data, it's about consistency, not
roles or permissions.

And params are form-specific, not of controller. They can be used with
different models, presenters and controllers.

One form can require :password, another one require :email, another one
require :full_name and permit to another field.

Another problem with StrongParameters - they ara introduce duplication
of responsibilities:

params.require(:user) # in controller

and

validates :user, :presence => true # model

What is difference between these approaches?

Resolution

Checking parameters (validation, requirements etc) must be extracted to
the dedicated class.

Reply to this email directly or view it on GitHub.

David Heinemeier Hansson

Reply to this email directly or view it on GitHubhttps://github.com//pull/7251#issuecomment-8824545.

äÁÎÉÌ ðÉÓØÍÅÎÎÙÊ
ôÅÈÎÉÞÅÓËÉÊ ÄÉÒÅËÔÏÒ


danil@investcafe.ru birg@investcafe.ru | www.investcafe.ru
éÎ×ÅÓÔËÁÆÅ | îÅÚÁ×ÉÓÉÍÏÅ ÁÎÁÌÉÔÉÞÅÓËÏÅ ÁÇÅÎÔÓÔ×Ï
íÏÂ.: +7 903 389-12-28
Skype: danil_pismenny

@dhh

This comment has been minimized.

Copy link
Member

dhh commented Sep 24, 2012

That abstraction does not offer any compelling benefit to me. But feel free to wrap it up like that in your application. You can wrap these form validators around the require/permit setup.

On Sep 24, 2012, at 11:56 AM, Danil Pismenny wrote:

I'm talking not about view's.

In real life Forms contains two parts.
First is a view (it's Formastic or so)
Second - some server-side object that requires and validates parameters (it
is missed in Rails)

The list of required and permitted parameters is linked to forms, not to
actions of controllers and not to models.

Example.

  1. RegistrationForm:
    = f.input :login
    = f.input :password
    = f.input :password_confirm

  2. Profile update form:
    = f.input :login
    = f.input :email
    = f.input :name

  3. Form for update password:
    = f.input :password
    = f.input :password_confirm

  4. Form of editing users for admins:
    = f.input :login
    = ..etc all parameters

  5. Form for second-lever users:
    = f.input :login
    = f.input :specific_field

In every form specific list of fields, specific list of required and
permitted fields.

In controller we must have something like this:

RegistrationFormVlidator.new.validate params
ProfileFormValidator.new.validate params
PasswordFormVlidator.new.validate params
etc

Every FormValidator requires and permits and also validates parameters in
their own way.

Yes we can have default UserFormValidator or specific role of current_user
to this FormValidator.

The key question is validation, not just requires and permits. And
extraction of these functions from controller to a separate class.

On Mon, Sep 24, 2012 at 8:14 PM, David Heinemeier Hansson <
notifications@github.com> wrote:

I have many forms pointing to the same controllers. Desktop and mobile web
views, APIs, etc. This verification also cannot be trusted to the view as
you don't want to tamper with it.

I wouldn't bother with the validates :user, :presence check if you feel
like you're duplicating yourself.

On Sep 24, 2012, at 10:25 AM, Danil Pismenny wrote:

Strong Prameters does not solve the problem of checking parameters in
Rails. The problem is model-based validation.

Require or not require, permit or not permit, validate and how to
validate - these are questions of the Form, not of a model and not of a
controller.

Model-based validation must be like SQL constraints - simple, basic and
unconditional. It's about solidity of data, it's about consistency, not
roles or permissions.

And params are form-specific, not of controller. They can be used with
different models, presenters and controllers.

One form can require :password, another one require :email, another one
require :full_name and permit to another field.

Another problem with StrongParameters - they ara introduce duplication
of responsibilities:

params.require(:user) # in controller

and

validates :user, :presence => true # model

What is difference between these approaches?

Resolution

Checking parameters (validation, requirements etc) must be extracted to
the dedicated class.

Reply to this email directly or view it on GitHub.

David Heinemeier Hansson

Reply to this email directly or view it on GitHubhttps://github.com//pull/7251#issuecomment-8824545.

äÁÎÉÌ ðÉÓØÍÅÎÎÙÊ
ôÅÈÎÉÞÅÓËÉÊ ÄÉÒÅËÔÏÒ


danil@investcafe.ru birg@investcafe.ru | www.investcafe.ru
éÎ×ÅÓÔËÁÆÅ | îÅÚÁ×ÉÓÉÍÏÅ ÁÎÁÌÉÔÉÞÅÓËÏÅ ÁÇÅÎÔÓÔ×Ï
íÏÂ.: +7 903 389-12-28
Skype: danil_pismenny

Reply to this email directly or view it on GitHub.

David Heinemeier Hansson

@shime

This comment has been minimized.

Copy link
Contributor

shime commented on 9bfa13b Oct 19, 2012

@guilleiguaran why is this extracted out?

This comment has been minimized.

Copy link
Member

steveklabnik replied Oct 19, 2012

Mass parameters is now in core as the proper way to handle model security.

This comment has been minimized.

Copy link
Contributor

shime replied Oct 20, 2012

@steveklabnik cool, thanks! So it uses ActiveModel::ForbidenAttributesProtection now?

This comment has been minimized.

Copy link
Member

steveklabnik replied Oct 20, 2012

You can see the plugin version here: http://gihub.com/rails/strong_parameters

This comment has been minimized.

Copy link
Contributor

shime replied Oct 20, 2012

This comment has been minimized.

Copy link
Member

robin850 replied Oct 20, 2012

@steveklabnik : you missed a "t" in your url. ^^ (https://github.com/rails/strong_parameters)

This comment has been minimized.

Copy link
Member

steveklabnik replied Oct 20, 2012

dammit. thanks

@tenderlove

This comment has been minimized.

why do we have an unused options hash? I hate options hashes, especially unused ones. :-P

This comment has been minimized.

Copy link
Member

carlosantoniodasilva replied Nov 9, 2012

I think that was supposed to be the role argument that exists in protected_attributes (which is also why the method got protected I think, since it's protected there?).

@tenderlove

This comment has been minimized.

why not use initialize_copy?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.