1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/actionpack/CHANGELOG.md

239 lines
7.3 KiB
Markdown
Raw Normal View History

2020-01-03 13:32:44 -05:00
* `ActionDispatch::Request.remote_ip` has ip address even when all sites are trusted.
Before, if all `X-Forwarded-For` sites were trusted, the `remote_ip` would default to `127.0.0.1`.
Now, the furthest proxy site is used. e.g.: It now gives an ip address when using curl from the load balancer.
*Keenan Brock*
* Fix possible information leak / session hijacking vulnerability.
The `ActionDispatch::Session::MemcacheStore` is still vulnerable given it requires the
gem dalli to be updated as well.
CVE-2019-16782.
* Include child session assertion count in ActionDispatch::IntegrationTest
`IntegrationTest#open_session` uses `dup` to create the new session, which
meant it had its own copy of `@assertions`. This prevented the assertions
from being correctly counted and reported.
2019-12-18 02:46:48 -05:00
Child sessions now have their `attr_accessor` overridden to delegate to the
root session.
Fixes #32142
*Sam Bostock*
* Add SameSite protection to every written cookie.
Enabling `SameSite` cookie protection is an addition to CSRF protection,
where cookies won't be sent by browsers in cross-site POST requests when set to `:lax`.
`:strict` disables cookies being sent in cross-site GET or POST requests.
Passing `:none` disables this protection and is the same as previous versions albeit a `; SameSite=None` is appended to the cookie.
See upgrade instructions in config/initializers/new_framework_defaults_6_1.rb.
More info [here](https://tools.ietf.org/html/draft-west-first-party-cookies-07)
_NB: Technically already possible as Rack supports SameSite protection, this is to ensure it's applied to all cookies_
*Cédric Fabianski*
* Bring back the feature that allows loading external route files from the router.
This feature existed back in 2012 but got reverted with the incentive that
https://github.com/rails/routing_concerns was a better approach. Turned out
that this wasn't fully the case and loading external route files from the router
can be helpful for applications with a really large set of routes.
Without this feature, application needs to implement routes reloading
themselves and it's not straightforward.
```ruby
# config/routes.rb
Rails.application.routes.draw do
draw(:admin)
end
# config/routes/admin.rb
get :foo, to: 'foo#bar'
```
*Yehuda Katz*, *Edouard Chin*
* Fix system test driver option initialization for non-headless browsers.
*glaszig*
* `redirect_to.action_controller` notifications now include the `ActionDispatch::Request` in
their payloads as `:request`.
*Austin Story*
2019-11-23 19:20:00 -05:00
* `respond_to#any` no longer returns a response's Content-Type based on the
request format but based on the block given.
2019-11-23 19:20:00 -05:00
Example:
2019-11-23 19:20:00 -05:00
```ruby
def my_action
respond_to do |format|
format.any { render(json: { foo: 'bar' }) }
end
end
get('my_action.csv')
```
The previous behaviour was to respond with a `text/csv` Content-Type which
is inaccurate since a JSON response is being rendered.
2019-11-23 19:20:00 -05:00
Now it correctly returns a `application/json` Content-Type.
2019-11-23 19:20:00 -05:00
*Edouard Chin*
* Replaces (back)slashes in failure screenshot image paths with dashes.
If a failed test case contained a slash or a backslash, a screenshot would be created in a
nested directory, causing issues with `tmp:clear`.
*Damir Zekic*
2019-11-23 19:20:00 -05:00
* Add `params.member?` to mimic Hash behavior.
*Younes Serraj*
* `process_action.action_controller` notifications now include the following in their payloads:
2019-11-04 18:29:38 -05:00
* `:request` - the `ActionDispatch::Request`
2019-11-16 08:17:01 -05:00
* `:response` - the `ActionDispatch::Response`
*George Claghorn*
* Updated `ActionDispatch::Request.remote_ip` setter to clear set the instance
`remote_ip` to `nil` before setting the header that the value is derived
from.
2019-11-23 19:20:00 -05:00
Fixes #37383.
*Norm Provost*
* `ActionController::Base.log_at` allows setting a different log level per request.
```ruby
# Use the debug level if a particular cookie is set.
class ApplicationController < ActionController::Base
log_at :debug, if: -> { cookies[:debug] }
end
```
*George Claghorn*
* Allow system test screen shots to be taken more than once in
a test by prefixing the file name with an incrementing counter.
Add an environment variable `RAILS_SYSTEM_TESTING_SCREENSHOT_HTML` to
enable saving of HTML during a screenshot in addition to the image.
This uses the same image name, with the extension replaced with `.html`
*Tom Fakes*
Add `Vary: Accept` header when rendering Problem description (quoted from @rafaelfranca's excellent explanation in https://github.com/rails/jquery-ujs/issues/318#issuecomment-88129005): > Let say that we requested /tasks/1 using Ajax, and the previous page has the same url. When we click the back button the browser tries to get the response from its cache and it gets the javascript response. With vary we "fix" this behavior because we are telling the browser that the url is the same but it is not from the same type what will skip the cache. And there's a Rails issue discussing about this problem as well https://github.com/rails/rails/issues/25842 Also, according to [RFC 7231 7.1.4](https://tools.ietf.org/html/rfc7231#section-7.1.4) > An origin server SHOULD send a Vary header field when its algorithm > for selecting a representation varies based on aspects of the request > message other than the method and request target we should add `Vary: Accept` header when determining content based on the `Accept` header. Although adding such header by default could cause unnecessary cache invalidation. But this PR only adds the header if: - The format param is not provided - The request is a `xhr` request - The request has accept headers and the headers are valid So if the user - sends request with explicit format, like `/users/1.json` - or sends a normal request (non xhr) - or doesn't specify accept headers then the header won't be added. See the discussion in https://github.com/rails/rails/issues/25842 and https://github.com/rails/rails/pull/36213 for more details.
2019-05-08 10:28:47 -04:00
* Add `Vary: Accept` header when using `Accept` header for response
For some requests like `/users/1`, Rails uses requests' `Accept`
header to determine what to return. And if we don't add `Vary`
in the response header, browsers might accidentally cache different
types of content, which would cause issues: e.g. javascript got displayed
instead of html content. This PR fixes these issues by adding `Vary: Accept`
in these types of requests. For more detailed problem description, please read:
https://github.com/rails/rails/pull/36213
2019-11-23 19:20:00 -05:00
Fixes #25842.
Add `Vary: Accept` header when rendering Problem description (quoted from @rafaelfranca's excellent explanation in https://github.com/rails/jquery-ujs/issues/318#issuecomment-88129005): > Let say that we requested /tasks/1 using Ajax, and the previous page has the same url. When we click the back button the browser tries to get the response from its cache and it gets the javascript response. With vary we "fix" this behavior because we are telling the browser that the url is the same but it is not from the same type what will skip the cache. And there's a Rails issue discussing about this problem as well https://github.com/rails/rails/issues/25842 Also, according to [RFC 7231 7.1.4](https://tools.ietf.org/html/rfc7231#section-7.1.4) > An origin server SHOULD send a Vary header field when its algorithm > for selecting a representation varies based on aspects of the request > message other than the method and request target we should add `Vary: Accept` header when determining content based on the `Accept` header. Although adding such header by default could cause unnecessary cache invalidation. But this PR only adds the header if: - The format param is not provided - The request is a `xhr` request - The request has accept headers and the headers are valid So if the user - sends request with explicit format, like `/users/1.json` - or sends a normal request (non xhr) - or doesn't specify accept headers then the header won't be added. See the discussion in https://github.com/rails/rails/issues/25842 and https://github.com/rails/rails/pull/36213 for more details.
2019-05-08 10:28:47 -04:00
*Stan Lo*
* Fix IntegrationTest `follow_redirect!` to follow redirection using the same HTTP verb when following
a 307 redirection.
*Edouard Chin*
* System tests require Capybara 3.26 or newer.
*George Claghorn*
* Reduced log noise handling ActionController::RoutingErrors.
*Alberto Fernández-Capel*
2019-11-23 19:20:00 -05:00
* Add DSL for configuring HTTP Feature Policy.
Adds support for configuring HTTP Feature Policy (#33439) A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy
2019-07-10 18:33:16 -04:00
This new DSL provides a way to configure an HTTP Feature Policy at a
Adds support for configuring HTTP Feature Policy (#33439) A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy
2019-07-10 18:33:16 -04:00
global or per-controller level. Full details of HTTP Feature Policy
specification and guidelines can be found at MDN:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy
2019-11-23 19:20:00 -05:00
Example global policy:
Adds support for configuring HTTP Feature Policy (#33439) A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy
2019-07-10 18:33:16 -04:00
2019-11-23 19:20:00 -05:00
```ruby
Adds support for configuring HTTP Feature Policy (#33439) A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy
2019-07-10 18:33:16 -04:00
Rails.application.config.feature_policy do |f|
f.camera :none
f.gyroscope :none
f.microphone :none
f.usb :none
f.fullscreen :self
f.payment :self, "https://secure.example.com"
Adds support for configuring HTTP Feature Policy (#33439) A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy
2019-07-10 18:33:16 -04:00
end
```
2019-11-23 19:20:00 -05:00
Example controller level policy:
Adds support for configuring HTTP Feature Policy (#33439) A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy
2019-07-10 18:33:16 -04:00
2019-11-23 19:20:00 -05:00
```ruby
Adds support for configuring HTTP Feature Policy (#33439) A HTTP feature policy is Yet Another HTTP header for instructing the browser about which features the application intends to make use of and to lock down access to others. This is a new security mechanism that ensures that should an application become compromised or a third party attempts an unexpected action, the browser will override it and maintain the intended UX. WICG specification: https://wicg.github.io/feature-policy/ The end result is a HTTP header that looks like the following: ``` Feature-Policy: geolocation 'none'; autoplay https://example.com ``` This will prevent the browser from using geolocation and only allow autoplay on `https://example.com`. Full feature list can be found over in the WICG repository[1]. As of today Chrome and Safari have public support[2] for this functionality with Firefox working on support[3] and Edge still pending acceptance of the suggestion[4]. #### Examples Using an initializer ```rb # config/initializers/feature_policy.rb Rails.application.config.feature_policy do |f| f.geolocation :none f.camera :none f.payment "https://secure.example.com" f.fullscreen :self end ``` In a controller ```rb class SampleController < ApplicationController def index feature_policy do |f| f.geolocation "https://example.com" end end end ``` Some of you might realise that the HTTP feature policy looks pretty close to that of a Content Security Policy; and you're right. So much so that I used the Content Security Policy DSL from #31162 as the starting point for this change. This change *doesn't* introduce support for defining a feature policy on an iframe and this has been intentionally done to split the HTTP header and the HTML element (`iframe`) support. If this is successful, I'll look to add that on it's own. Full documentation on HTTP feature policies can be found at https://wicg.github.io/feature-policy/. Google have also published[5] a great in-depth write up of this functionality. [1]: https://github.com/WICG/feature-policy/blob/master/features.md [2]: https://www.chromestatus.com/feature/5694225681219584 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801 [4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy [5]: https://developers.google.com/web/updates/2018/06/feature-policy
2019-07-10 18:33:16 -04:00
class PagesController < ApplicationController
feature_policy do |p|
p.geolocation "https://example.com"
end
end
```
*Jacob Bednarz*
* Add the ability to set the CSP nonce only to the specified directives.
Fixes #35137.
*Yuji Yaginuma*
* Keep part when scope option has value.
When a route was defined within an optional scope, if that route didn't
take parameters the scope was lost when using path helpers. This commit
ensures scope is kept both when the route takes parameters or when it
doesn't.
Fixes #33219.
*Alberto Almagro*
* Added `deep_transform_keys` and `deep_transform_keys!` methods to ActionController::Parameters.
*Gustavo Gutierrez*
* Calling `ActionController::Parameters#transform_keys`/`!` without a block now returns
an enumerator for the parameters instead of the underlying hash.
*Eugene Kenny*
* Fix strong parameters blocks all attributes even when only some keys are invalid (non-numerical).
It should only block invalid key's values instead.
*Stan Lo*
2019-04-24 15:57:14 -04:00
Please check [6-0-stable](https://github.com/rails/rails/blob/6-0-stable/actionpack/CHANGELOG.md) for previous changes.