Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Rails 5 default settings #4141

Merged
merged 10 commits into from
Oct 6, 2020
Merged

Use Rails 5 default settings #4141

merged 10 commits into from
Oct 6, 2020

Conversation

javierm
Copy link
Member

@javierm javierm commented Sep 24, 2020

References

Objectives

  • Use the settings used in Rails 5 applications
  • Make it obvious why our application doesn't always use the default Rails 5 settings

@javierm javierm added this to Reviewing in Consul Democracy via automation Sep 24, 2020
@javierm javierm self-assigned this Sep 24, 2020
@javierm javierm mentioned this pull request Sep 24, 2020
The goal here is to have a notion on what the defaults are in a Rails 5
application, know why our application is working in a different way
(it's because these defaults aren't loaded in an application which was
originally developed using Rails 4), and have an explicit list of things
we are overwriting.

Furthermore, running the `app:update` rake task to upgrade to Rails 5.2
will by default add the line loading default options for Rails 5.0, so
by adopting those default options we prevent accidental mistakes when
upgrading.

We'll have to review these items and see which ones can be changed to
their default values for Rails 5 applications.
This is the default for new Rails application, and adds an extra layer
of security since now the token will only be valid for its action, and
so attackers managing to change the form action will not do any harm
since the CSRF token will not work for the attackers' action.

Note that we've had InvalidAuthenticityToken exceptions for years; if we
keep getting them, chances are this change is *not* related.
This is the default in Rails 5 applications.

This option is not enabled by default in existing applications because
it would break applications running on several domains and doing POST
requests between them or running a reverse proxy that rewrites the Host
header. Since those aren't our cases, it's safe to enable it.
Quoting the Rails DateAndTime::Compatibility module:

> With Ruby 2.4+ the default for +to_time+ changed from
> converting to the local system time, to preserving the offset
> of the receiver. For backwards compatibility we're overriding
> this behavior

We don't need backwards compatibility in our application because we
aren't converting any time objects to the local system timezone but use
the application timezone all the time instead.
The default options (which apply when `force_ssl` is set, which is the
default in CONSUL) are `{ hsts: { subdomains: true } }`, which means we
tell browsers to apply our SSL settings to subdomains as well [1].
CONSUL installations implementing multitenancy with subdomains will
benefit from this change.

[1] https://api.rubyonrails.org/classes/ActionDispatch/SSL.html
Changing it would mean reviewing and changing all our existing models,
and some of them might be tricky (like our Document and Image models,
which only validate certain associations in some cases), so we're
keeping it the way it's been until now.
This option was added by Rails 4 new application generator. However, the
`assets.digest` option is set to true by default, and recent Rails
versions don't even add this option to the environment files.
This way we know what we need to do to fully upgrade to Rails 5.1.
This is the default in Rails 5.1 applications. If we want to use an
asset in the public folder, we need to add the `public_folder: true`
option, making it clear that we don't expect the asset to be in the
asset pipeline.

Since we don't use `asset_path` to reference assets in the public
folder, we can safely disable the `unknown_asset_fallback` option.
We're not replacing `form_for` with `form_with` for now, and even if we
did, most of our forms are not remote, so making them remote by default
would be inconvenient.
Consul Democracy automation moved this from Reviewing to Testing Oct 6, 2020
@javierm javierm merged commit 9efec56 into master Oct 6, 2020
Consul Democracy automation moved this from Testing to Release 1.3.0 Oct 6, 2020
@javierm javierm deleted the load_defaults branch October 6, 2020 13:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants