| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
| |
There is no controller instance when using a redirect route or a
mounted rack application so pass the request object as the context
when resolving dynamic CSP sources in this scenario.
Fixes #34200.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if a dynamic source returned a symbol such as :self it
would be converted to a string implicity, e.g:
policy.default_src -> { :self }
would generate the header:
Content-Security-Policy: default-src self
and now it generates:
Content-Security-Policy: default-src 'self'
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
this method (#34210)
* Fix `ActionController::Parameters#each_value`
`each_value` should yield with "value" of the params instead of "value" as an array.
Related to #33979
* Add changelog entry about `ActionController::Parameters#each_value`.
Follow up #33979
|
| |
|
|
| |
ActiveSupport::ParameterFilter
|
| |\
| |
| |
| | |
Don't handle params option in a special way in url_for helper
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Fixing code block rendering, indentation, backticks, etc.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When running with code triage and derailed benchmarks and focusing on this file:
Before
16199 /Users/rschneeman/Documents/projects/rails/actionpack/lib/action_controller/metal/strong_parameters.r
After
2280 /Users/rschneeman/Documents/projects/rails/actionpack/lib/action_controller/metal/strong_parameters.rb
|
| |/
|
|
|
|
|
|
|
|
| |
Remove the reference to the PR.
Usually, we write reference to solved issues in the changelog files.
Related to #33605.
Add missing dots.
Improve formatting.
|
| | |
|
| |
|
|
| |
[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.
|
| | |
|
