We initially did that to avoid a browser being restarted to display a
cached form with a stale CSRF token – thus provoking an
InvalidAuthenticityToken exception when the form is submitted.
But now that we use a long-lived CSRF token, we can submit forms with
a stale CSRF token successfully (because the long-lived CSRF cookie)
is still valid – so we no longer need to change the HTML cache behavior.
This fixes issues where the browser Back button wants to display a
previous POST document, but can't because of the 'no-store' setting. In
this case the browser either displays an error, or re-attempts the POST
request (without any cookies), which results in an
InvalidAuthenticityToken exception.
See `docs/adr-csrf-forgery.md` for more explanations.
With Rails 6.1, the default queue is now the global application queue.
We want to retain our custom queues in some cases, so configure them
epxlicitely.
Rationale:
- `lib/` is supposed to contain code mostly independant from Rails;
- By default, Rails doesn't eager-load `lib/` anymore (this used to be
the case, but since a few releases).
If this commits triggers some errors, then these errors should be fixed
(rather that `lib/` being added again to the load path).
Stop overriding Rails 5.0 options, and use the framework defaults.
(Except for `active_record.belongs_to_required_by_default`, which is a
lot of work and will be fixed later.)
This instruct browsers to never cache content directly generated by the
controllers. This includes HTML pages, JSON responses, PDF files, etc.
This is because Some mobile browsers have a behaviour where, although
they will delete the session cookie when the browser shutdowns, they
will still serve a cached version of the page on relaunch.
The CSRF token in the HTML is then mismatched with the CSRF token in the
session cookie (because the session cookie has been cleared). This
causes form submissions to fail with an
"ActionController::InvalidAuthenticityToken" exception.
To prevent this, tell browsers to never cache the HTML of a page.
(This doesn’t affect assets files, which are still sent with the proper
cache headers).
See https://github.com/rails/rails/issues/21948
