CORS error seen by specific account only

sebalis

This is a copy of a GitHub issue that I just submitted without being aware that I should have tried this forum instead.

I co-administrate a CryptPad instance that I updated to v2025.3.1 three days ago. After the update, one user reports that when logged in with their account, CryptPad becomes almost unusable, while other accounts, including newly created accounts by the same person in the same browser, do not have a problem. I have been able to reproduce their problem using Chromium on my computer. My Chromium profile is set to forget all data on closing the browser, and is always used in incognito mode. I would therefore rule out the browser cache being part of the problem. Various other fresh profiles in Chromium, Firefox and other browsers have also been tried. The issue is consistent and again, this problem only occurs with this one account. For example, closing and opening my Chromium instance and then trying it with my own account showed everything to be working fine.

Here are the symptoms from a user point of view:

Only one tab showing any CryptPad content ever works. This even applies if the open tabs are on different devices. Any further tabs get stuck in the loading process. When opening the personal CryptDrive, the well-known “disconnected” message is shown. As double-clicking on a document would open it in a new tab, the only way to access a document is to copy its edit URL and paste it into the address bar of that same tab. This way, a document can in fact be opened.

I was also able to observe the following:

The error console reports CORS errors for requests to content on the main domain from an origin on the UI domain. This is followed by several similar errors and failing GET requests, which I attribute to the first problem. This also does not occur with my own account in the same Chromium profile. Here is a sample message: Access to XMLHttpRequest at 'https://cryptpad.XYZ/blob/XY/XY...' from origin 'https://ui.cryptpad.XYZ' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

For the time being, I decided not to mention the instance here. The problem would seem impossible to reproduce anyway, as we cannot make these account’s credentials available. I do not know of any other account being affected.

Are there any ideas where I should look?

sebalis

After some further analysis, I have realised that these extra CORS errors were generated because during the loading phase at least for the personal drive, this account will try to retrieve some BLOBs that do not exist.

I do not know why there would be an attempt to retrieve inexistent resources and I think I need to resolve this somehow. Retrieving a non-existent resource leads to CORS errors because when using the suggested NGINX advanced configuration, 404 responses are sent without the Access-Control-Allow-Origin header. I have therefore added “always” to the relevant line in the config file. Now 404 responses no longer cause a CORS error, but they still show up as (now slightly different) errors in the browser console. I assume that this will cause an exception that breaks some required JavaScript operation.

Is there anything you can share about 404 requests in some account? This is a heavily used account that has been around for a long time, so it might somehow contain pointers to documents that no longer exist. Sadly, using the settings section does not work either, so I don’t know how to retrieve the CryptDrive’s contents in order to migrate to a new account.

Mathilde

Hello!

sebalis After some further analysis, I have realised that these extra CORS errors were generated because during the loading phase at least for the personal drive, this account will try to retrieve some BLOBs that do not exist.

Did you face a data loss? Do you have backups so you could try restoring files?

sebalis

Mathilde Thanks for checking in :-) No data loss as far as we know so far, but it feels like there’s a looming threat of data loss as the settings page already is stuck in loading (even when it is the only tab loading, see symptoms above). So no way of creating a backup (hence my other question), and who knows if at some point it will become impossible to load some document. Sadly, no backup was created before the problem occurred.

Mathilde

sebalis as you are hosting the instance I was talking about sysadmin backups, not a drive export from the user side. Especially since you are mentioning missing blobs. If you have a backup you could try to restore those.

sebalis

Mathilde Silly me – yes, we have backups. I will see if I can find these blobs. Where do I need to look: the blob directory obviously, anywhere else?

sebalis

Mathilde Well, it would have been too easy, I guess :-) After restoring 9 missing blobs, there are no further 404 errors. Now this user either gets no more messages than I get in my working account, or in their own browser there are some other messages about two things: 1. CSP settings blocking inline scripts (script-src-elem); and 2. CSP settings (report-only rule) blocking worker scripts blocked due to “worker-src 'none'”, combined with another line saying that the report URL should not be about:blank but an HTTP or HTTPS URL. The wording is not exact as I’m translating and summarising. But as I said, that occurs only in the user’s browser (Firefox 139.0.1. on Ubuntu 22.04, custom settings or extensions unknown) and when I ask them to try in my Firefox (English, 139.0.4 on Debian Bookworm, set to forget data on close) they now only get the errors that I see too, but the user-centric symptoms remain as before.