When an exception is raised, `response.json()` may have been called
already. In that case, when accessing `response.text()` in the error
handler, a "Response.text: Body has already been
consumed." error will be raised.
This fixes an issue where, by default, links to private attachments are
reported to Matomo.
This is benign: attachments URLs can be filtered out server-side, and
expire after one hour anyway. But we don't want to ship an insecure
configuration by default.
When a new "Menu" type de champ is added, it comes pre-filled with a
menu title – and nothing else. Which is confusing, and invalid.
Instead pre-fill the type de champ with actual values (no titles).
The /api/pays API requires user authentication. However older versions
of Edge and Safari don't transmit cookies by default during a
`fetch` request.
Use the `credentials: 'same-origin'` option explicitely to fix the
countries list.
Before, when a 401 was received by a ujs-enabled link (like `link_to …,
method: :delete, data: { remote: true }`, rails-ujs tried to insert the
response text as a Javascript script.
As the script was something like `Please sign-in`, which is not valid
Javascript, the browser would throw an "Unexpected token" error.
The typical use-case is:
1. The user open a form in a tab,
2. The user disconnects in another tab,
3. In the first tab, the user clicks on a remote "Delete" link_to
In that case the browser raised an error in the console (and in Sentry),
but the user would see nothing.
With this commit, all 401 ujs errors are turned into redirects to the
sign-in page.
Fix https://sentry.io/organizations/demarches-simplifiees/issues/2522512693/activity/
Sentry reports many cases of the xhr object being missing in the
error handler.
Ensure the error handling code doesn't crash because of the missing xhr.
There are two cases where the draft auto-save might fail because the
user is no longer authenticated:
- The user signed-out in another tab,
- The brower quit and re-opened, so the Session cookie expired.
In both cases, the auto-save will never succeed until the user
authenticates again, so displaying a "Retry" button is cruel.
Moreover, in plus of all auto-save requests failing with a small error,
the actual hard failure only occurs after filling all the form and
trying to submit it. Then the user is redirected to the sign-in page –
but all their changes are lost.
Instead, we now redirect to the sign-in page on the first 401 error
during the auto-save, let the user sign-in, and then redirect back to
the form.
