We have quite a lot of `Error reading file` errors when uploading files.
These errors are generated by ActiveStorage `file_checksum.js` component
but it eats the actual reason of errors.
(See https://github.com/rails/rails/blob/5-2-stable/activestorage/app/javascript/activestorage/file_checksum.js#L38)
We can't really override the class to generate better errors, as they
are deeply nested in ActiveStorage class hierarchy, and not exported to
external code.
Instead, we hook into the FileReader event handler, to insert a logger
when this error occur. The original event handler will also still be
called as usual.
This is intended to be temporary. The debug code will be removed once
we get a better idea of what is going on.
When running the app using `bin/webpack-dev-server` (the external
(and fast) assets server), LiveReload is used. We need to explicitely
allow the LiveReload connections in the CSP policy.
Turns out we now need to specify the protocol explicitely.
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.
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
In Sentry, when an `ActionController::InvalidAuthenticityToken` error
occurs, the breadcrumbs mention that before hitting the error, the user
clicked on one of those links.
Unfortunately we don't know which one. For debugging purposes, adding
classes to the links should allow us to see which links users are
navigating to.
