| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|\ |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Renames _handle_render_options to _render_to_body_with_renderer, which is more
intention-revealing.
* The name of the dynamically generated method for a renderer with key :js was
"_render_option_js".
That name is too weak. :js is an option if you see the render argument as just
a generic options hash, but in the context of renderers that's the renderer
key, is what identifies the renderer.
Now "_render_with_renderer_js" is generated instead, which is crystal clear.
* The name of the dynamically generated method for the renderer was constructed
using string literals in a few places. That is now encapsulated in a method.
* Since we were on it, also removed a couple of redundant selfs.
|
|\
| |
| | |
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.
|
|\ \
| | |
| | | |
Update `ActionController::Parameters` to be more secure on parameters handling
|
| | |
| | |
| | |
| | | |
Ruby 1.9.3 does not implement Hash#to_h, so we can't call `super` on it.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* `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/lib/action_controller/metal/mime_responds.rb
actionview/lib/action_view/vendor/html-scanner/html/sanitizer.rb
activerecord/lib/active_record/type/value.rb
|
| | |
| | |
| | |
| | | |
[skip ci]
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
respond_with (and consequently the class-level respond_to)
are being removed from Rails. Instead of moving it to a 3rd
library, the functionality will be moved to responders gem
(at github.com/plataformatec/responders) which already provides
some responders extensions.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
New default: the template digest is automatically included in your ETags.
When you call `fresh_when @post`, the digest for `posts/show.html.erb`
is mixed in so future changes to the HTML will blow HTTP caches for you.
This makes it easy to HTTP-cache many more of your actions.
If you render a different template, you can now pass the `:template`
option to include its digest instead:
fresh_when @post, template: 'widgets/show'
Pass `template: false` to skip the lookup. To turn this off entirely, set:
config.action_controller.etag_with_template_digest = false
|
| |
| |
| |
| | |
This follows the good practice listed on http://guides.rubyonrails.org/debugging_rails_applications.html#impact-of-logs-on-performance.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
[ci skip]
|
|
|
|
| |
Closes #16170
|
|
|
|
|
|
|
|
|
|
|
|
| |
`render nothing: true` or rendering a `nil` body no longer add a single
space to the response body.
The old behavior was added as a workaround for a bug in an early version of
Safari, where the HTTP headers are not returned correctly if the response
body has a 0-length. This is been fixed since and the workaround is no
longer necessary.
Use `render body: ' '` if the old behavior is desired.
|
|
|
|
|
|
| |
Adds a comment before JSONP callbacks. See
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ for more
details on the exploit in question.
|
|\
| |
| | |
Improve token_and_options regex and test
|
| |
| |
| |
| | |
add a test case to test the regex for the helper method raw_params
|
|/
|
|
|
|
|
| |
The controller can set the response format as 'JSON' before the renderer code be
evaluated, so we must replace it when necessary.
Fixes #15081
|
|\
| |
| |
| |
| |
| | |
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 commit adds back the always_permitted_parameters
configuration option to strong paramaters.
* The initial pull requests where this feature was added
are the following:
- https://github.com/rails/rails/pull/12682
- https://github.com/rails/strong_parameters/pull/174
|
| |
| |
| |
| |
| | |
Need to add individual `:nodoc:` for nested classes / modules to completely
remove the constants from the API.
|
| | |
|
|\ \
| | |
| | |
| | | |
ActionController::Parameters#require now accepts FalseClass values
|
|/ /
| |
| |
| | |
Fixes #15685.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The 401 status should be set first because setting the response body in
a live controller also closes the response to further changes.
Fixes #14229.
|
| |
| |
| |
| | |
.. even when the producer is blocked for a write.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| | |
Per convention, underscore-only argument names should be used for unused parameters.
|
| |
| |
| |
| |
| |
| | |
memory leak demonstrated on @tenderlove's latest blog post:
http://tenderlovemaking.com/2014/06/02/yagni-methods-are-killing-me.html
|
| | |
|