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
Merged

Integrate strong_parameters in Rails 4 #7251

merged 23 commits into from Sep 18, 2012

Conversation

@guilleiguaran
Copy link
Member

@guilleiguaran guilleiguaran commented Aug 3, 2012

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

@@ -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
Copy link
Member

@rafaelfranca 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
Copy link
Contributor

@josevalim 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
Copy link
Contributor

@spastorino 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
Copy link
Contributor

@spastorino 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
Copy link
Member

@rafaelfranca 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
Copy link
Contributor

@spastorino 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
Copy link
Contributor

@spastorino spastorino commented Aug 4, 2012

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

@guilleiguaran
Copy link
Member Author

@guilleiguaran guilleiguaran commented Aug 7, 2012

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

@homakov
Copy link
Contributor

@homakov homakov commented Aug 13, 2012

❤️

@kirs
Copy link
Member

@kirs kirs commented Aug 13, 2012

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

@dmathieu
Copy link
Contributor

@dmathieu 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.

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
Copy link
Member Author

@guilleiguaran 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
Copy link
Member Author

@guilleiguaran 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 18 commits Jul 18, 2012
…Hash instead of monkey patch permitted? method in regular hashes
dhh added a commit that referenced this pull request Sep 18, 2012
@dhh dhh merged commit c49d959 into master Sep 18, 2012
1 check passed
1 check passed
@josevalim
default The Travis build passed
Details
@dapi
Copy link

@dapi 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
Copy link
Member

@steveklabnik 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
Copy link
Member

@dhh 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
Copy link

@dapi 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
Copy link
Member

@dhh 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 shime commented on 9bfa13b Oct 19, 2012

@guilleiguaran why is this extracted out?

This comment has been minimized.

Copy link
Member

@steveklabnik 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 shime replied Oct 20, 2012

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

This comment has been minimized.

Copy link
Member

@steveklabnik 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 shime replied Oct 20, 2012

This comment has been minimized.

Copy link
Member

@robin850 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 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 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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet