In https://github.com/rails/rails/pull/39939 we automatically set `Link` header for each stylesheet and script.
In https://github.com/rails/rails/pull/40882 we added `config.action_view.preload_links_header` option
to configure whether `stylesheet_link_tag` and `javascript_include_tag`
should set automatically `Link` header.
This commit adds test to make sure that it is disabled by default
for updated apps that haven't adopted new '6.1' defaults.
Also, added changes to Configuring guide
- Mentioned this option in "Results of `config.load_defaults`" section
- Mentioned this option in "Baseline defaults:" section (see ff881137a8ceab951211a66afa2389ae599b2ce7)
As mentioned in
https://github.com/rails/rails/pull/40770#issuecomment-748347066 we
should default to SHA256 where SHA1 is used today. This switches over
the ActiveSupport::Digest to use SHA256 for new applications.
It also updates the constants to always refer to and use the OpenSSL
constants as well, as also discussed in that PR.
This change allows for configuration of the hash digest that is used in
the key generator for key derivation.
SHA1 is an outdated algorithm and security auditors tend to frown on
its usage. By allowing this to be configured, it becomes possible to
move to a more up to date hash mechanism.
While I don't think this has any current relevant security implications,
especially not with a proper random secret base, moving away from SHA1
makes conversations with auditors and FIPS compliance checks easier
since the best answer is always that an approved algorithm is used.
A rotation can be built using this change with an approach like the
following for encrypted cookies:
```ruby
Rails.application.config.active_support.key_generator_hash_digest_class = OpenSSL::Digest::SHA256
Rails.application.config.action_dispatch.cookies_rotations.tap do |cookies|
salt = Rails.application.config.action_dispatch.authenticated_encrypted_cookie_salt
secret_key_base = Rails.application.secrets.secret_key_base
key_generator = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000, hash_digest_class: OpenSSL::Digest::SHA1)
key_len = ActiveSupport::MessageEncryptor.key_len
secret = key_generator.generate_key(salt, key_len)
cookies.rotate :encrypted, secret
end
```
This turns the default into using SHA256 but also still accepts secrets
derived using SHA1.
The defaults for new apps is here changed to use SHA256. Existing apps
will keep using SHA1.
PR #39939 added support for the `Link` header being generated
automatically when using `stylesheet_link_tag` and
`javascript_include_tag`. However not everything should be
preloaded, e.g. a link to a legacy IE stylesheet has no need to be
preloaded because IE doesn't support the header and in some browsers it
will trigger the preload even though it's not used since it's inside an
IE conditional comment. This leads to increased bandwith costs and
slower application performance.
To allow more flexibility for sites that may have complex needs for the
`Link` header this commit adds a configuration option that disables it
completely and leaves it up to the application to decide how to handle
generating a `Link` header.
This change broke config.active_job.queue_name_prefix with eager-loading enabled (i.e. in production, by default).
This reverts commit a173a657309f03016f24b7a3d8a24c846e5ab331, reversing
changes made to 89414f561a672e98d8d6deda39d358fc6e0c0386.
Browser native support for lazy loading images is now a part of the
official HTML standard. To indicate to the browser that an image should
be lazily loaded, add the `loading="lazy"` attribute to the `img` tag.
Or, in Rails parlance, add the `loading: "lazy"` option to the
`image_tag` call.
This commit adds `Rails.application.config.action_view.image_loading` to
configure the default value of the `image_tag` `:loading` option. Thus
by setting `config.action_view.image_loading = "lazy"`, an application
can opt in to lazy loading images sitewide, without changing view code.
`form_with` would generate a remote form by default.
This confused users because they were forced to handle remote requests.
All new 6.1 applications will generate non-remote forms by default.
When upgrading a 6.0 application you can enable remote forms by default by
setting `config.action_view.form_with_generates_remote_forms` to `true`.
Since #37850, `config_for` returns `nil` instead of an empty Hash when
a config file does not contain configuration for the specified
environment. Thus, the return value should be converted to a Hash
before calling `with_indifferent_access`.
Fixes#40548.
This change allows for a connection to be swapped on role or shard for a
class. Previously calling `connected_to` would swap all the connections
to a particular role or shard. Granular connection swapping is useful
for swapping one connection to reading while leaving all other
connection classes on writing.
The public methods on connection handler have been updated to behave the
same as they did previously on the different handlers. The difference
however is instead of calling
`ActiveRecord::Base.connection_handlers[:reading].clear_all_connections!`
you now call
`ActiveRecord::Base.connection_handler.clear_all_connections!` which
will clear based on current role set by a `connected_to` block. Outside
the context of a `connected_to` block, `clear_all_connections!` can take
an optional parameter to clear specific connections by role.
The major changes in this PR are:
* We introduced a `legacy_connection_handling` configuration option that
is set to true by default. It will be set to `false` for all new
applications.
* In the new connection handling there will be one only connection
handler. Previously there was a connection handler for each role. Now
the role is stored in the `PoolManager`. In order to maintain backwards
compatibility we introduced a `LegacyPoolManager` to avoid duplicate
conditionals. See diagram in PR body for changes to connection
management.
* `connected_to` will now use a stacked concurrent map to keep track of
the connection for each class. For each opened block the `class`,
`role`, and `shard` will be added to the stack, when the block is exited
the `class`, `role`, `shard` array will be removed from the stack.
* With these changes `ActiveRecord::Base.connected_to` will remain
global. If called all connections in the block will use the `role` and
`shard` that was switched to. If called with a parent class like
`AnimalsRecord.connected_to` only models under `AnimalsRecord` will be
switched and everything else will remain the same.
Examples:
Given an application we have a `User` model that inherits from
`ApplicationRecord` and a `Dog` model that inherits from
`AnimalsRecord`. `AnimalsRecord` and `ApplicationRecord` have writing
and reading connections as well as shard `default`, `one`, and `two`.
```ruby
ActiveRecord::Base.connected_to(role: :reading) do
User.first # reads from default replica
Dog.first # reads from default replica
AnimalsRecord.connected_to(role: :writing, shard: :one) do
User.first # reads from default replica
Dog.first # reads from shard one primary
end
User.first # reads from default replica
Dog.first # reads from default replica
ApplicationRecord.connected_to(role: :writing, shard: :two) do
User.first # reads from shard two primary
Dog.first # reads from default replica
end
end
```
Things this PR does not solve:
* Currently there is no API for swapping more than one but not all
connections. Apps with many primaries may want to swap 3 but not all 10
connections. We plan to build an API for that in a followup PR.
* The middleware remains the same and is using the global switching
methods. Therefore at this time to use this new feature applications
must manually switch connections. We will also address this in a
followup PR.
* The `schema_cache` is currently on the `PoolConfig`. We plan on trying
to move this up to the `PoolManager` or elsewhere later on so each
`PoolConfig` doesn't need to hold a reference to the `schema_cache`.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Sometimes cascading association deletions can cause timeouts due to
an IO issue. Perhaps a model has associations that are destroyed on
deletion which in turn trigger other deletions and this can continue
down a complex tree. Along this tree you may also hit other IO
operations. Such deep deletions can lead to server timeouts while
awaiting completion and really the user may not notice all the
changes on their side immediately making them wait unnecesarially or
worse causing a timeout during the operation.
We now allow associations supporting the `dependent:` key to take `:destroy_async`,
which schedules a background job to destroy associations.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
Co-authored-by: Cory Gwin @gwincr11 <gwincr11@github.com>
Right now it's already possible to set a digest class manually, but this
is not through a publicly supported and approved API. With these
configuration options, it is possible to configure a digest class to use
for digests inside Rails.
The reason for this is that it allows configuring other classes in
certain conditions like running in FIPS mode. FIPS disallows MD5 and
discourages SHA1. Even though this isn't used in Rails for security
related things, using newer hash algorithms means not having to explain
it to auditors which always makes life easier.
That's not the only reason though. If today Ruby is built and running
for example in an Ubuntu 18.04 FIPS approved environment, the default
Digest classes break, see https://bugs.ruby-lang.org/issues/13681 as
well.
By allowing a class to be configured, the following can be used so that
things work properly (using the new API proposed here):
```
Rails.application.config.active_support.hash_digest_class = OpenSSL::Digest::SHA256
```
This would then use the OpenSSL certified FIPS implementation as well.
I recently learned that Rails logs at the :debug level (not the :info
level) by default in production environments. This is a surprising
behaviour, as other popular frameworks do not log at this level
by default. It would not be surprising if a developer accidentally
logged personally identifiable information (PII) in a production
environment due to this behaviour.
I noticed that [in 2014](https://github.com/rails/rails/pull/16622), the
Rails project made an intentional decision to set the default log level
to :debug. However, the landscape around logging PII has changed since
then with the introduction of legislation like GDPR, so I thought it
prudent to reopen this discussion.
Fixes#40031
While removing deprecated non-symbol access to nested `config_for`
hashes in #37876, we also broke `config_for` for anyone using the
[safe_yaml] gem. The problem is that `safe_yaml` patches `YAML.load` in
a way that doesn't honor the `symbolize_names` options (I believe this
is on purpose, to prevent symbol-based DOS attacks).
In the description of #37876 there is mention of the fact that this was
the first place in Rails we used `symbolize_names`, and that
`deep_symbolize_keys` had been used in the past.
This commit switches over to `deep_symbolize_keys` to allow `config_for`
to continue working for people using [safe_yaml].
[safe_yaml]: https://rubygems.org/gems/safe_yaml
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.
This reverts commit 0f9249c93f402d276730fcfaba1ed1b876ee7c26.
Reverted because this wasn't warning in custom jobs and therefore
applications may have not seen the deprecation. We'll need to fix the
deprecation to warn for custom jobs so that applications can migrate.
In the past, we sometimes hit missing `Symbol#start_with?` and
`Symbol#end_with?`.
63256bc5d7a8e812964d
So I proposed `Symbol#start_with?` and `Symbol#end_with?` to allow duck
typing that methods for String and Symbol, then now it is available in
Ruby 2.7.
https://bugs.ruby-lang.org/issues/16348
Using `String#starts_with?` and `String#ends_with?` could not be gained
that conveniency, so it is preferable to not use these in the future.
These were removed in 74201c3885ae2e33bfff046d503324fd1d7a320f when the
template for the 6.0 new framework defaults initializer was deleted.
While we no longer generate the file, upgrading applications will still
have it, so it's still important to check that these options can be set.
I introduced this pattern of referencing a constant to trigger lazy load
hooks in 458a5502a17ccf58d5708a3b030ac9917a0a8476, and it arrived at its
current form via c98a641ff402d3ca5b754f4621a0764f33eab155 and
c24be369322b9e0211fcef30003375de195ef660.
I now realise autoloading doesn't need to be involved at all; we can
require the files that trigger the lazy load hooks directly.
* require, require_relative, load by double quotes
We're getting rid of all single quote usage, unless it serves a specific purpose, as per the general style guide.
