| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
- Tests for dup'ing params was separately added in a separate file in
https://github.com/rails/rails/pull/25735.
|
|
|
|
|
|
| |
`#initialize_copy` to manually duplicate the underlying parameters hash
It looks like `ActionController::Parameters#dup` is leftover from when the class inherited from `Hash`. We can just trust `#dup`, which already copies the `@permitted` instance variable (confirmed by tests). We still define a `#initialize_copy` to make `@parameters` a copy that can be mutated without affecting the original instance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When `ActionController::Parameters` is duplicated with `#dup`, it doesn't create a duplicate of the instance variables (e.g. `@parameters`) but rather maintains the reference (see <http://ruby-doc.org/core-2.3.1/Object.html>). Given that the parameters object is often manipulated as if it were a hash (e.g. with `#delete` and similar methods), this leads to unexpected behaviour, like the following:
```
params = ActionController::Parameters.new(foo: "bar")
duplicated_params = params.dup
duplicated_params.delete(:foo)
params == duplicated_params
```
This fixes the bug by defining a private `#initialize_copy` method, used internally by `#dup`, which makes a copy of `@parameters`.
|
|\
| |
| | |
Renamed NestedParametersTest to NestedParametersPermitTest
|
| |
| |
| |
| | |
what we are actually testing in this file
|
| |
| |
| |
| |
| | |
In the docs: "+permit_all_parameters+ - If it's +true+, all the parameters will
be permitted by default. The default is +false+."
|
|/
|
|
|
|
| |
This brings the behavior more inline with other similar cases, such as
receiving a hash when an array of scalars was expected. Prior to this
commit, the key would be present, but the value would be `nil`
|
|
|
|
|
|
| |
This method will only be added when used with Ruby 2.3.0 or greater.
This method has the same behavior as `Hash#dig`, except it will convert
hashes to `ActionController::Parameters`, similar to `#[]` and `#fetch`.
|
|
|
|
| |
- Fixes #23822.
|
| |
|
|
|
|
| |
Creating a protected getter method for `@parameters`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While iterating an AC::Parameters object, the object will mutate itself
and stick AC::Parameters objects where there used to be hashes:
https://github.com/rails/rails/blob/f57092ad728fa1de06c4f5fd9d09dcc2c4738fd9/actionpack/lib/action_controller/metal/strong_parameters.rb#L632
If you use `permit` after this iteration, the `fields_for_style` method
wouldn't return true because the child objects are now AC::Parameters
objects rather than Hashes.
fixes #23701
|
|
|
|
| |
Now that AC::Parameters is no longer a Hash, it shouldn't look like a hash.
|
|
|
|
| |
`NEVER_UNPERMITTED_PARAMS` is deprecated in Rails 4.2. See #15933.
|
|
|
|
| |
See bug #21032.
|
|\
| |
| | |
test `include?`- fix typo
|
| | |
|
|/
|
|
|
|
| |
Fixes #23026
See discussion at #23026
|
|\
| |
| | |
Fix AC::Parameters#to_unsafe_h to return all unfiltered values
|
| |
| |
| |
| |
| |
| |
| | |
- AC::Parameters#convert_parameters_to_hashes should return filtered or
unfiltered values based on whether it is called from `to_h` or `to_unsafe_h`
instead of always defaulting to `to_h`.
- Fixes #22841
|
|/
|
|
| |
- Test should call `to_unsafe_h` instead of `to_h`
|
|
|
|
| |
Fixes #22818
|
|
|
|
|
|
|
|
| |
When calling `to_h` on an `ActionController::Parameters` instance it would
`deep_dup` its internal parameters.
This inadvertently called `dup` on a passed Active Record model which would
create new models. Fix by only dupping Ruby's Arrays and Hashes.
|
|
|
|
|
|
|
| |
This makes these two methods to be more inline with the previous
behavior of Parameters as Parameters used to be inherited from HWIA.
Fixes #21391
|
| |
|
|
|
|
| |
method_call_assertions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This clears the transaction record state when the transaction finishes
with a `:committed` status.
Considering the following example where `name` is a required attribute.
Before we had `new_record?` returning `true` for a persisted record:
```ruby
author = Author.create! name: 'foo'
author.name = nil
author.save # => false
author.new_record? # => true
```
|
|
|
|
|
|
|
|
|
| |
When executing an `ActionController::Parameters#fetch` with a block
that raises a `KeyError` the raised `KeyError` will be rescued and
converted to an `ActionController::ParameterMissing` exception,
covering up the original exception.
[Jonas Schubert Erlandsson & Roque Pinel]
|
| |
|
|
|
|
|
|
|
|
| |
This is another take at #14384 as we decided to wait until `master` is
targeting Rails 5.0. This commit is implementation-complete, as it
guarantees that all the public methods on the hash-inherited Parameters
are still working (based on test case). We can decide to follow-up later
if we want to remove some methods out from Parameters.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of ActionController::Parameters.const_missing
returns `ActionController::Parameters.always_permitted_parameters` even
if its `super` returns a constant without raising error. This prevents its
subclass in a autoloading module/class from taking advantage of
autoloading constants.
class SomeParameters < ActionController::Parameters
def do_something
DefinedSomewhere.do_something
end
end
In the code above, `DefinedSomewhere` is to be autoloaded with
`Module.const_missing` but `ActionController::Parameters.const_missing`
returns `always_permitted_parameters` instead of the autoloaded
constant.
This pull request fixes the issue respecting `const_missing`'s `super`.
|
|
|
|
|
|
|
|
|
| |
As suggested in #16299([1]), this method should be a new public API for
retrieving unfiltered parameters from `ActionController::Parameters`
object, given that `Parameters#to_hash` will no longer work in Rails
5.0+ as we stop inheriting `Parameters` from `Hash`.
[1]: https://github.com/rails/rails/pull/16299#issuecomment-50220919
|
|
|
|
|
|
|
| |
* `each`
* `each_pair`
* `delete`
* `select!`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to make sure that `permitted` status is maintained on the
resulting object.
I found these methods that needs to be redefined by looking for
`self.class.new` in the code.
* extract!
* transform_keys
* transform_values
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`ActionController::Parameters#to_h` now returns a `Hash` with
unpermitted keys removed. This change is to reflect on a security
concern where some method performed on an `ActionController::Parameters`
may yield a `Hash` object which does not maintain `permitted?` status.
If you would like to get a `Hash` with all the keys intact, duplicate
and mark it as permitted before calling `#to_h`.
params = ActionController::Parameters.new(name: 'Senjougahara Hitagi')
params.to_h # => {}
unsafe_params = params.dup.permit!
unsafe_params.to_h # => {"name"=>"Senjougahara Hitagi"}
safe_params = params.permit(:name)
safe_params.to_h # => {"name"=>"Senjougahara Hitagi"}
This change is consider a stopgap as we cannot chage the code to stop
`ActionController::Parameters` to inherit from
`HashWithIndifferentAccess` in the next minor release.
Also, adding a CHANGELOG entry to mention that
`ActionController::Parameters` will not inheriting from
`HashWithIndifferentAccess` in the next major version.
|
|\
| |
| |
| |
| |
| | |
Add always permitted parameters as a configurable option.
[Rafael Mendonça França + Gary S. Weaver]
|
| |
| |
| |
| |
| |
| | |
* General style fixes.
* Add changes to configuration guide.
* Add missing tests.
|
| | |
|
| |
| |
| |
| | |
This is a regression test for 29844dd.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot cache keys because arrays are mutable. We rather want to cache
the arrays. This behaviour is tailor-made for the usage pattern strongs
params is designed for.
In a forthcoming commit I am going to add a test that covers why we need
to cache by value.
Every strong params instance has a live span of a request, the cache goes
away with the object. Since strong params have such a concrete intention,
it would be interesting to see if there are actually any real-world use
cases that are an actual leak, one that practically may matter.
I am not convinced that the theoretical leak has any practical consequences,
but if it can be shown there are, then I believe we should either get rid of
the cache (which is an optimization), or else wipe it in the mutating API.
This reverts commit e63be2769c039e4e9ada523a8497ce3206cc8a9b.
|
| |
| |
| |
| |
| |
| | |
memory leak demonstrated on @tenderlove's latest blog post:
http://tenderlovemaking.com/2014/06/02/yagni-methods-are-killing-me.html
|
| |
| |
| |
| | |
when only 1 parameter is unpermitted.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
#13382]
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
sebasoga/change_strong_parameters_require_behaviour"
This reverts commit c2b5a8e61ba0f35015e6ac949a5c8fce2042a1f2, reversing
changes made to 1918b12c0429caec2a6134ac5e5b42ade103fe90.
See: https://github.com/rails/rails/pull/9660#issuecomment-27627493
|
|\ \
| | |
| | |
| | |
| | | |
sebasoga/change_strong_parameters_require_behaviour
Change ActionController::Parameters#require behavior when value is empty
|