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.
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/
Currently ProgressBar is used to monitor upload progress of attachments.
But there's two cases where the associated DOM element may be removed:
- In the champs editor, when the list scrolls, DOM elements are removed
and added dynamically by React;
- In the user form, the user might start an upload on a repetition, and
then remove the associated row during the download.
In both those cases, we don't want the missing DOM element to trigger
an error.
When subclassing a JS error, most browsers include the constructor
stacktrace :/
This is an issue, because:
- The stacktrace is deeper than it should be
- The stacktrace reaches into a polyfill for which there is not source
map, which causes Sentry to infer the issue grouping from the JS file
name. And the fingerprinted name changes on each release. So for each
release, the stacktrace is different ; and Sentry can't group issues
properly.
A DirectUpload may fail for several reasons, and return many types of
errors (string, xhr response, Error objects, etc).
For convenience, wrap all these errors in a FileUploadError object.
- It makes easier for clients of the Uploader class to handle errors;
- It allows to propagate the error code and failure responsability.
