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

317 lines
9.9 KiB
Markdown
Raw Normal View History

* `remote_ip` will no longer ignore IPs in X-Forwarded-For headers if they
are accompanied by port information.
*Duncan Brown*, *Prevenios Marinos*
* `fixture_file_upload` now uses path relative to `file_fixture_path`
Previously the path had to be relative to `fixture_path`.
You can change your existing code as follow:
```ruby
# Before
fixture_file_upload('files/dog.png')
# After
fixture_file_upload('dog.png')
```
*Edouard Chin*
* Remove deprecated `force_ssl` at the controller level.
*Rafael Mendonça França*
* The +helper+ class method for controllers loads helper modules specified as
strings/symbols with `String#constantize` instead of `require_dependency`.
Remember that support for strings/symbols is only a convenient API. You can
always pass a module object:
```ruby
helper UtilsHelper
```
which is recommended because it is simple and direct. When a string/symbol
is received, `helper` just manipulates and inflects the argument to obtain
that same module object.
*Xavier Noria*, *Jean Boussier*
* Correctly identify the entire localhost IPv4 range as trusted proxy.
*Nick Soracco*
* `url_for` will now use "https://" as the default protocol when
`Rails.application.config.force_ssl` is set to true.
*Jonathan Hefner*
* Accept and default to base64_urlsafe CSRF tokens.
Base64 strict-encoded CSRF tokens are not inherently websafe, which makes
them difficult to deal with. For example, the common practice of sending
the CSRF token to a browser in a client-readable cookie does not work properly
out of the box: the value has to be url-encoded and decoded to survive transport.
Now, we generate Base64 urlsafe-encoded CSRF tokens, which are inherently safe
to transport. Validation accepts both urlsafe tokens, and strict-encoded tokens
for backwards compatibility.
*Scott Blum*
* Support rolling deploys for cookie serialization/encryption changes.
In a distributed configuration like rolling update, users may observe
both old and new instances during deployment. Users may be served by a
new instance and then by an old instance.
That means when the server changes `cookies_serializer` from `:marshal`
to `:hybrid` or the server changes `use_authenticated_cookie_encryption`
from `false` to `true`, users may lose their sessions if they access the
server during deployment.
We added fallbacks to downgrade the cookie format when necessary during
deployment, ensuring compatibility on both old and new instances.
*Masaki Hara*
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.
2020-02-25 00:14:54 -05:00
* 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.
2020-02-25 00:14:54 -05:00
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*
2020-02-25 00:14:54 -05:00
* Add `Vary: Accept` header when using `Accept` header for response.
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
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.