| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
When `render` was moved from ActionPack to ActionView in acc8e259,
some fixtures required by the tests were duplicated, but they are
actually only required by ActionView tests.
To give one example, `double_render` is already defined [in the AV tests](https://github.com/rails/rails/blob/72139d8d310d896db78eaec98582c7a638135102/actionview/test/actionpack/controller/render_test.rb#L407)
and is never used in the ActionPack tests.
|
|
|
|
| |
test response.
|
|\
| |
| | |
Add test case and documentation for skip_before_filter.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new test/docs further explain the conflicts that can happen when
mixing `:if`/`:unless` options with `:only`/`:except` options in
`skip_before_action`.
The gist is that "positive" filters always have priority over negative
ones.
The previous commit already showed that `:only` has priority over `:if`.
This commit shows that `:if` has priority over `:except`.
For instance, the following snippets are equivalent:
```ruby
skip_before_action :some_callback, if: -> { condition }, except: action
```
```ruby
skip_before_action :some_callback, if: -> { condition }
```
|
| |
| |
| |
| |
| |
| |
| |
| | |
Test case for using skip_before_filter with the options :only and :if
both present. In this case, the :if option will be ignored and :only
will be executed.
Closes #14549 (the commit was cherry-picked from there).
|
| | |
|
|/ |
|
|
|
|
| |
This functionality has been extracted to the responders gem.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Ensure append_info_to_payload is called even if an exception is raised.
Conflicts:
actionpack/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| |
| | |
See:
* https://github.com/rails/rails/pull/14903
* https://github.com/roidrage/lograge/issues/37
Some code by mxrguspxrt from #14903.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Commit 20fece1 introduced the `_status_code` method to fix calls to
`head :ok`. This method has been added on both ActionController::Metal
and ActionDispatch::Response.
As for the latter, this method is just equivalent to the `response_code`
one so commit aefec3c removed it from the `Reponse` object so call to
the `_status_code` method on an ActionController::Base instance would be
handled by the `Metal` class (which `Base` inherits from) but the status
code is not updated according to the response at this level.
The fix is to actually rely on `response_code` for ActionController::Base
instances but this method doesn't exist for bare Metal controllers so we
need to define it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- The single space response was added due to a bug in safari
in https://github.com/rails/rails/commit/cb0f8fda9652c4d24d04693bdb82cecd3b067e5c
and
https://github.com/rails/rails/commit/807df4fcf021fc4d15972aa1c17ba7398d43ab0d.
- This was removed from the `render nothing: true` in
https://github.com/rails/rails/pull/14883.
- Removing it from response of :head also. As :head is more obvious
alternative to call `render nothing:
true`(http://guides.rubyonrails.org/layouts_and_rendering.html#using-head-to-build-header-only-responses),
removing it from head method also.
- Closes #18253.
|
|\ \
| | |
| | |
| | |
| | | |
jethroo/fix/assert_template_with_unsupported_layout_type
assert template should raise ArgumentError for unsupported layout types
|
| |/
| |
| |
| | |
unknown layout type
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an `around_action` does not `yield`, then the corresponding action is
*never* executed and the `after_` actions are *never* invoked.
The value returned by the `around_action` does not have any impact on this:
an `around_action` can "return" `true`, `false`, or `"pizza"`, but as long
as `yield` is not invoked, the corresponding action and after callbacks are
not executed.
The test suite for `ActionController::Callbacks` currently includes separate
tests to distinguish the cases in which a non-yielding `around_actions` returns
`true` or `false`.
In my opinion, having such tests is misleading, giving the impression that the
returned value might have some sort of impact, while it does not. At least
that's the impression I got when I read those tests.
For completeness, the tests were introduced 7 years ago by @NZKoz in e80fabb.
|
|/
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|\
| |
| |
| | |
Allow authentication header to not have to specify 'token=' key.
|
| |
| |
| |
| | |
Fixes: https://github.com/rails/rails/issues/17108.
|
|\ \
| | |
| | | |
Do not rescue Exception in ActionDispatch::ParamsParser
|
| | |
| | |
| | |
| | |
| | | |
Unlike ShowExceptions or PublicExceptions, ParamsParser shouldn't
transform exceptions like Interrupt and NoMemoryError into ParserError.
|
|\ \ \ |
|
|/ / /
| | |
| | |
| | | |
url_for
|
| | |
| | |
| | |
| | | |
Reference #17453
|
|/ /
| |
| |
| |
| | |
These are currently working "by accident" because `match_route` does not check
that the name is valid.
|
| |
| |
| |
| |
| |
| | |
Reference #17453
[Godfrey Chan, Washington Luiz]
|
| |
| |
| |
| | |
Fixes https://github.com/rails/rails/issues/17714.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit f93df52845766216f0fe36a4586f8abad505cac4, reversing
changes made to a455e3f4e9dbfb9630d47878e1239bc424fb7d13.
Conflicts:
actionpack/lib/action_controller/test_case.rb
actionview/lib/action_view/test_case.rb
|
| |
| |
| |
| | |
Closes #17586
|
| |
| |
| |
| |
| |
| | |
We added a deprecation warning for these cases in aa1fadd, so these are now
causing deprecation warnings in the test output. AFAICT, in these two cases, the
option is not integral to the purpose of the test, so they can be safely removed
|
| |
| |
| |
| |
| |
| | |
Follow up to 212057b9. Since that commit, we need to pass the `route_name`
explicitly. This is one of the left-over cases that was not handled in that
commit, which was causing `use_route` to be ignored in functional tests.
|
| |
| |
| |
| | |
Fixes: https://github.com/rails/rails/issues/16814
|
| | |
|
| |
| |
| |
| |
| |
| | |
See comment in this patch for the rationale.
References #16468
|
|/
|
|
| |
[related #17233]
|
|
|
|
| |
This is to match the changes in Rails Dom Testing rails/rails-dom-testing#20.
|
|
|
|
|
|
| |
Hash#keys.each allocates an array of keys; Hash#each_key iterates through the
keys without allocating a new array. This is the reason why Hash#each_key
exists.
|
| |
|
|\
| |
| | |
CSRF token mask from breach-mitigation-rails gem
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This merges in the code from the breach-mitigation-rails gem that masks
authenticity tokens on each request by XORing them with a random set of
bytes. The masking is used to make it impossible for an attacker to
steal a CSRF token from an SSL session by using techniques like the
BREACH attack.
The patch is pretty simple - I've copied over the [relevant
code](https://github.com/meldium/breach-mitigation-rails/blob/master/lib/breach_mitigation/masking_secrets.rb)
and updated the tests to pass, mostly by adjusting stubs and mocks.
|
| |
| |
| |
| |
| |
| |
| | |
* `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.
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
actionpack/CHANGELOG.md
|
| | | |
|