| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nesting respond_to calls can lead to unexpected behavior, so it should be
avoided. Currently, the first respond_to format match sets the content-type
for the resulting response. But, if a nested respond_to occurs, it is possible
to match on a different format. For example:
respond_to do |outer_type|
outer_type.js do
respond_to do |inner_type|
inner_type.html { render body: "HTML" }
end
end
end
Browsers will often include */* in their Accept headers. In the above example,
such a request would result in the outer_type.js match setting the content-
type of the response to text/javascript, while the inner_type.html match will
cause the actual response to return "HTML".
This change tries to minimize potential breakage by only raising an exception
if the nested respond_to calls are in conflict with each other. So, something
like the following example would not raise an exception:
respond_to do |outer_type|
outer_type.js do
respond_to do |inner_type|
inner_type.js { render body: "JS" }
end
end
end
While the above is nested, it doesn't affect the content-type of the response.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add implicit to path conversion to uploaded file
Ruby has a few implicit conversion protocols (e.g. `to_hash`, `to_str`,
`to_path`, etc.). These are considered implicit conversion protocols
because in certain instances Ruby (MRI core objects) will check if an
argument responds to the appropriate protocol and automatically convert
it when it does; this is why you can provide a `Pathname` instance into
`File.read` without having to explicitly call `to_s`.
```ruby
a_file_path = 'some/path/file.ext'
File.write a_file_path, 'String Path Content'
File.read a_file_path
a_pathname = Pathname(a_file_path)
File.write core_file, 'Pathname Content'
File.read a_file_path
core_file = File.new(a_pathname)
File.write core_file, 'File Content'
File.read core_file
tmp_file = Tempfile.new('example')
File.write tmp_file, 'Tempfile Content'
File.read tmp_file
```
So how does an uploaded file work in such cases?
```ruby
tmp_file = Tempfile.new('example')
File.write tmp_file, 'Uploaded Content'
uploaded_file = ActionDispatch::Http::UploadedFile.new(tempfile: tmp_file)
File.read uploaded_file
```
It fails with a `TypeError`:
no implicit conversion of ActionDispatch::Http::UploadedFile into String
In order to make an uploaded file work it must be explicitly converted
to a file path using `path`.
```ruby
File.read uploaded_file.path
```
This requires any code that expects path/file like objects to either
special case an uploaded file, re-implement the path conversion protocol
to use `path`, or forces the developer to explicitly cast uploaded files
to paths. This last option can sometimes be difficult to do when such
calls are deep within the inner workings of libraries.
Since an uploaded file already has a path it makes sense to implement
the implicit "path" conversion protocol (just like `File` and
`Tempfile`). This change allows uploaded file content to be treated more
closely to regular file content, without requiring any special case
handling or explicit conversion for common file utilities.
* Note uploaded file path delegation in CHANGELOG
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a `get` method called with `as: :json` and `params: nil` or
`params: false` (explicitly or implicitly)
`RequestEncoder#encode_params` converts it into a `null` or `false`
value which includes a unexpected `null=` or `false` query string into
request URL. From now on `RequestEncoder#encode_params` checks whether
`params` is nil or not otherwise returns.
Move down `nil` conversion guard
Update CHANGELOG.md
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Allow get arguments for follow_redirect
Now all arguments passed to `follow_redirect!` are passed to the
underlying `get` method. This for example allows to set custom headers
for the redirection request to the server.
This is especially useful for setting headers that may, outside of the
testing environment, be set automatically on every request, i.e. by a
web application firewall.
* Allow get arguments for follow_redirect
[Remo Fritzsche + Rafael Mendonça França]
|
|
|
|
| |
I spotted it while working on a PR.
|
|\
| |
| |
| | |
Create MissingExactTemplate exception with separate template
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Plugins interacting with the exceptions caught and displayed by
ActionDispatch::DebugExceptions currently have to monkey patch it to get
the much needed exception for their calculation.
With DebugExceptions.register_interceptor, plugin authors can hook into
DebugExceptions and process the exception, before being rendered. They
can store it into the request and process it on the way back of the
middleware chain execution or act on it straight in the interceptor.
The interceptors can be play blocks, procs, lambdas or any object that
responds to `#call`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
bogdanvlviv/add-missing-changelog-for-32593"
This reverts commit 78ff47f3e77925f72d98579da6feb68f36052ad8, reversing
changes made to daffe03308bffc43ea343a886aab33082d83bb9c.
That changelog entry should only be on 5-2-stable
|
| |
| |
| |
| |
| |
| |
| |
| | |
https://github.com/rails/rails/pull/32593 was backported to
`5-2-stable` but since 5.2.0 is released the changelog entry should
be in Rails 6.0.0 too.
[ci skip]
|
| |
| |
| |
| |
| |
| | |
Pull Request #32602 fixes Issue #32597.
[ci skip]
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
ActionDispatch's default headers are now moved into their own module that are by default included in both Base and API. This allows API-mode applications to take advantage of the default security headers, as well as providing an easy way to add more.
|
| |
| |
| |
| |
| |
| |
| | |
In #32446 was added method `dig` to `session`.
Improve docs of method `dig`.
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Today there are two common ways for Rails developers to force their
applications to communicate over HTTPS:
* `config.force_ssl` is a setting in environment configurations that
enables the `ActionDispatch::SSL` middleware. With this middleware
enabled, all HTTP communication to your application will be redirected
to HTTPS. The middleware also takes care of other best practices by
setting HSTS headers, upgrading all cookies to secure only, etc.
* The `force_ssl` controller method redirects HTTP requests to certain
controllers to HTTPS.
As a consultant, I've seen many applications with misconfigured HTTPS
setups due to developers adding `force_ssl` to `ApplicationController`
and not enabling `config.force_ssl`. With this configuration, many
application requests can be served over HTTP such as assets, requests
that hit mounted engines, etc. In addition, because cookies are not
upgraded to secure only in this configuration and HSTS headers are not
set, it's possible for cookies that are meant to be secure to be sent
over HTTP.
The confusion between these two methods of forcing HTTPS is compounded
by the fact that they share an identical name. This makes finding
documentation on the "right" method confusing.
HTTPS throughout is quickly becomming table stakes for all web sites.
Sites are expected to operate over HTTPS for all communication,
sensitive or otherwise. Let's encourage use of the broader-reaching
`ActionDispatch::SSL` middleware and elminate this source of user
confusion. If, for some reason, applications need to expose certain
endpoints over HTTP they can do so by properly configuring
`config.ssl_options`.
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| |
| |
| |
| | |
* Check exclude before flagging cookies as secure.
* Update comments in ActionDispatch::SSL.
[Catherine Khuu + Rafael Mendonça França]
|
| |
| |
| |
| |
| |
| | |
We only add the header when releasing to avoid some conflicts.
[ci skip]
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Because the UJS library creates a script tag to process responses it
normally requires the script-src attribute of the content security
policy to include 'unsafe-inline'.
To work around this we generate a per-request nonce value that is
embedded in a meta tag in a similar fashion to how CSRF protection
embeds its token in a meta tag. The UJS library can then read the
nonce value and set it on the dynamically generated script tag to
enable it to execute without needing 'unsafe-inline' enabled.
Nonce generation isn't 100% safe - if your script tag is including
user generated content in someway then it may be possible to exploit
an XSS vulnerability which can take advantage of the nonce. It is
however an improvement on a blanket permission for inline scripts.
It is also possible to use the nonce within your own script tags by
using `nonce: true` to set the nonce value on the tag, e.g
<%= javascript_tag nonce: true do %>
alert('Hello, World!');
<% end %>
Fixes #31689.
|
|/
|
|
|
|
| |
Skipping over 2.4.0 to sidestep the `"symbol_from_string".to_sym.dup` bug.
References #32028
|
| |
|
|
|
|
| |
:tada::tada::tada:
|
| |
|
| |
|
| |
|
|
|
|
| |
haven't specified manually another server.
|
|
|
|
| |
default headers set.
|
| |
|
|
|
|
| |
Since this changes a default setting a changelog entry is important.
|
| |
|
| |
|
|
|
|
| |
Fixes #31220.
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
Make `assert_recognizes` to traverse mounted engines
|
| |
| |
| |
| |
| |
| | |
Before this commit paths of mounted engines are not traversed
when `assert_recognizes` is called, causing strange test results.
This commit enable to traverse mounted paths.
|
| | |
|
| |
| |
| |
| |
| |
| | |
method [ci skip]
Related to #30850
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When puma/puma#1403 is merged Puma will support the Early Hints status
code for sending assets before a request has finished.
While the Early Hints spec is still in draft, this PR prepares Rails to
allowing this status code.
If the proxy server supports Early Hints, it will send H2 pushes to the
client.
This PR adds a method for setting Early Hints Link headers via Rails,
and also automatically sends Early Hints if supported from the
`stylesheet_link_tag` and the `javascript_include_tag`.
Once puma supports Early Hints the `--early-hints` argument can be
passed to the server to enable this or set in the puma config with
`early_hints(true)`. Note that for Early Hints to work
in the browser the requirements are 1) a proxy that can handle H2,
and 2) HTTPS.
To start the server with Early Hints enabled pass `--early-hints` to
`rails s`.
This has been verified to work with h2o, Puma, and Rails with Chrome.
The commit adds a new option to the rails server to enable early hints
for Puma.
Early Hints spec:
https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-04
[Eileen M. Uchitelle, Aaron Patterson]
|
| | |
|
| |
| |
| |
| |
| |
| | |
Using the action_dispatch.cookies_rotations interface, key rotation is
now possible with cookies. Thus the secret_key_base as well as salts,
ciphers, and digests, can be rotated without expiring sessions.
|
| | |
|