These are super basic issues that were flagged by the axe browser
extension.
I tried to change as few things as possible to avoid breaking anything
that might be making assumptions about the markup on this page.
Generally, there is a lot more work that would need to be done on these
pages to make them as friendly as possible to assistive technologies.
Relevant:
- https://dequeuniversity.com/rules/axe/4.1/landmark-one-main
- https://dequeuniversity.com/rules/axe/4.1/color-contrast
https://github.com/rails/rails/pull/39461 changed the `no-store`
directive for the `Cache-Control` header to be exclusive, i.e. when
setting `Cache-Control` to `private, no-store`, this is simplified to
just `no-store`. `private` should typically be superfluous there, but
it's not always.
For instance, Fastly "does not currently respect no-store or no-cache
directives" and says that "if you need to prevent caching by both Fastly
and web browsers, we recommend combining the private directive with
max-age=0 or no-store".
https://docs.fastly.com/en/guides/configuring-caching#do-not-cache
Since it's not possible to override this directive reduction behaviour,
the changes in #39461 prevent Fastly users from upgrading Rails.
This changes the behaviour to allow setting a 'private, no-store' header
when private is specified - similar to how 'public' can be specified
when 'no-cache' is, but not as a default.
Fixes https://github.com/rails/rails/issues/40798
Currently, the payload of the unpermitted_parameters.action_controller
events emitted by StrongParameters does not provide enough information for
developers to understand which controller and action received the
unpermitted parameters. This PR modifies ActionController::Parameters to
allow callers to specify a "context" which is included in the logging
payload.
*Implementation Strategy*
Since the ActionController::Parameters class is only loosely coupled
with controllers and can technically be used in any context, this PR
expects the caller to provide logging context.
Since StrongParameters is caller in Rails and has access to the
request object I chose to provide a payload similar to the
start_processing.action_controller event.
* Add ActionController::Live::Buffer#writeln to write a line to the stream with a newline included
* Don't add newlines to strings that already have them
When throw was used in a controller action, and there is matching catch
around the request in a Rack middleware, then :exception won't be
present in the event payload.
This is because ActiveSupport::Notifications::Instrumenter.instrument
sets :exception in a rescue handler, but rescue is never called in a
throw/catch scenario:
catch(:halt) do
begin
throw :halt
rescue Exception => e
puts "rescue" # never reached
ensure
puts "ensure"
end
end
Missing :exception was actually handled prior to Rails 6.1.0, but an
optimization updated the code to assume this was present. So this can be
considered a regression fix.
Similar to #38998 (fixed in #40246), HTTP method validation occurring whenever methods are called on `ActionDispatch::Request` can cause some weird unintended consequences. For example, if `config.exceptions_app = self.routes`, you get an exception raised via the `ActionDispatch::ShowExceptions` middleware failsafe:
```
Started TEST "/" for 127.0.0.1 at 2020-11-05 15:40:31 -0500
(1.0ms) SELECT "schema_migrations"."version" FROM "schema_migrations" ORDER BY "schema_migrations"."version" ASC
TEST, accepted HTTP methods are OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY, ORDERPATCH, ACL, SEARCH, MKCALENDAR, and PATCH excluded from capture: DSN not set
ActionController::UnknownHttpMethod (TEST, accepted HTTP methods are OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY, ORDERPATCH, ACL, SEARCH, MKCALENDAR, and PATCH):
actionpack (6.0.3.4) lib/action_dispatch/http/request.rb:431:in `check_method'
actionpack (6.0.3.4) lib/action_dispatch/http/request.rb:143:in `request_method'
rack (2.2.3) lib/rack/request.rb:187:in `head?'
actionpack (6.0.3.4) lib/action_dispatch/journey/router.rb:113:in `find_routes'
actionpack (6.0.3.4) lib/action_dispatch/journey/router.rb:32:in `serve'
actionpack (6.0.3.4) lib/action_dispatch/routing/route_set.rb:834:in `call'
Error during failsafe response: TEST, accepted HTTP methods are OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY, ORDERPATCH, ACL, SEARCH, MKCALENDAR, and PATCH
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/http/request.rb:431:in `check_method'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/http/request.rb:143:in `request_method'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/request.rb:187:in `head?'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/journey/router.rb:113:in `find_routes'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/journey/router.rb:32:in `serve'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/routing/route_set.rb:834:in `call'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/middleware/show_exceptions.rb:50:in `render_exception'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/middleware/show_exceptions.rb:36:in `rescue in call'
/usr/local/var/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/actionpack-6.0.3.4/lib/action_dispatch/middleware/show_exceptions.rb:31:in `call'
# ...
```
Now, to prevent the redundant exception, we overwrite `request_method` before passing `env` down to `config.exceptions_app`. `action_dispatch.original_request_method` is set to keep the original request method available for inspection.
Fixes#40772
The `RemoteIp` middleware currently behaves inconsistently depending on
whether `config.action_dispatch.trusted_proxies` is configured with a
single value or an enumerable.
- Deprecate ability to assign a single value to `trusted_proxies` in
`RemoteIp` middleware
- Add an explicit test for the setting overriding the default list of
trusted proxies
In the same way that requests may need to be excluded from forced SSL,
requests may also need to be excluded from the Host Authorization
checks. By providing this additional flexibility more applications
will be able to enable Host Authorization while excluding requests
that may not conform. For example, AWS Classic Load Balancers don't
provide a Host header and cannot be configured to send one. This means
that Host Authorization must be disabled to use the health check
provided by the load balancer. This change will allow an application
to exclude the health check requests from the Host Authorization
requirements.
I've modified the `ActionDispatch::HostAuthorization` middleware to
accept arguments in a similar way to `ActionDispatch::SSL`. The hosts
configuration setting still exists separately as does the
hosts_response_app but I've tried to group the Host Authorization
settings like the ssl_options. It may make sense to deprecate the
global hosts_response_app if it's only used as part of the Host
Authorization failure response. I've also updated the existing tests
as the method signature changed and added new tests to verify the
exclusion functionality.
by setting `config.action_dispatch.request_id_header` to the desired value
* Ensure HTTP_X_REQUEST_ID presence to maintain compatiblility
* Use req.headers[] to fetch header rather than ENV methods
* Update configuration doc to match existing descriptions
* Add changelog entry for action_dispatch.request_id_header
* Add binary encoding logic into ActionDispatch::Request::Utils
Moving the logic to set binary encoding into ActionDispatch::Request::Utils
will allow us to encode from GET and POST in ActionDispatch::Request.
* Refactor binary encoding logic
- Move binary encoding calls into GET, POST and path_parameters
- Remove binary encoding from ActionDispatch::Http::Request
- This way, we only raise an invalid encoding exception if the controller is not requesting
parameters in binary encoding
* Check if encoding is valid in ActionDispatch::Request#POST and raise BadRequest if invalid
* Fix multipart_params_test that has binary-encoded params containing invalid UTF-8 characters
* Address PR comments
* Pass action and controller to Request::Utils.set_binary_encoding
[Rafael Mendonça França + Adrianna Chang]
308 status code introduced in https://tools.ietf.org/html/rfc7538
preserves the request method unlike 301 status code which would convert
POST requests to GET.
Prior to this commit, when multiple cookie domains were specified, the
first domain that was a substring of the request host was chosen. This
allowed, for example, the "example.com" domain to be chosen when the
request host was "example.com.au" or even "myexample.com".
This commit ensures a domain is chosen only if it is equal to or is a
superdomain of the request host.
Fixes#37760.
When using an external build process (webpack, grunt) it's helpful for
rails to be able to serve those assets. Brotli has better compression
than gzip and should eventually replace it for static assets.
When using an external build process (webpack, grunt) it's helpful for
rails to be able to serve those assets. Brotli has better compression
than gzip and will eventually replace it for static assets.
Rack decided to tolerate proxies which choose to attach ports to
X-Forwarded-For IPs by stripping the port:
https://github.com/rack/rack/pull/1251. Attaching a port is rare in the
wild but some proxies (notably Microsoft Azure's App Service) do it.
Without this patch, remote_ip will ignore X-Forwarded-For IPs with ports
attached and the return value is less likely to be useful.
Rails should do the same thing. The stripping logic is already available
in Rack::Request::Helpers, so change the X-Forwarded-For retrieval
method from ActionDispatch::Request#x_forwarded_for (which returns the
raw header) to #forwarded_for, which returns a stripped array of IP
addresses, or nil. There may be other benefits hiding in Rack's
implementation.
We can't call ips_from with an array (and legislating for that inside
ips_from doesn't appeal), so refactor out the bit we need to apply in
both cases (verifying the IP is acceptable to IPAddr and that it's not a
range) to a separate method called #sanitize_ips which reduces an array of
maybe-ips to an array of acceptable ones.
- We used the `fixture_path` before `file_fixture_path` was a thing,
but now that we have the latter we should use it.
`fixture_path` is solely used by Active Record so it seems wrong
to be using that in ActionPack.
Motivation is twofold:
* We are gradually removing `require_dependency` from the framework.
* Let `helper` work if `config.add_autoload_paths_to_load_path` is
disabled.
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
`url_for` will now use "https://" as the default protocol when
`Rails.application.config.force_ssl` is set to true.
Action Mailer already behaves this way, effectively. This commit
extends that behavior application-wide.
Closes#23543.
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.
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.
