app: restore the default cache settings

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.
This commit is contained in:
Pierre de La Morinerie 2021-07-06 17:30:29 +02:00
parent 831672391e
commit 5b4f7f9ae9

View file

@ -41,18 +41,6 @@ module TPS
default_allowed_tags = ActionView::Base.sanitized_allowed_tags default_allowed_tags = ActionView::Base.sanitized_allowed_tags
config.action_view.sanitized_allowed_tags = default_allowed_tags + ['u'] config.action_view.sanitized_allowed_tags = default_allowed_tags + ['u']
# 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
# a "ActionController::InvalidAuthenticityToken" exception.
# To prevent this, tell browsers to never cache the HTML of a page.
# (This doesnt affect assets files, which are still sent with the proper cache headers).
#
# See https://github.com/rails/rails/issues/21948
config.action_dispatch.default_headers['Cache-Control'] = 'no-store, no-cache'
# ActionDispatch's IP spoofing detection is quite limited, and often rejects # ActionDispatch's IP spoofing detection is quite limited, and often rejects
# legitimate requests from misconfigured proxies (such as mobile telcos). # legitimate requests from misconfigured proxies (such as mobile telcos).
# #