Login on Firefox not possible due to bogus CORS error

[tanius]

Firefox 72.0 here. We use a custom home server. Login works in Chrome, and also in Firefox when using a Private Window.

But login does not work in Firefox when using a normal window. Then, I get the following error messages in the developer tools console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://example.com/.well-known/matrix/client. (Reason: CORS request did not succeed).

rageshake.js:104:31
No response or error when parsing .well-known

rageshake.js:104:31
CORS request rejected: https://example.com/.well-known/matrix/client
    r rageshake.js:104
    t autodiscovery.js:404
    u runtime.js:45
    _invoke runtime.js:271
    t runtime.js:97
    n asyncToGenerator.js:3
    s asyncToGenerator.js:25

Error processing homeserver config: 
Object { state: "FAIL_PROMPT", error: "Invalid homeserver discovery response", base_url: null }

rageshake.js:104:31
Problem parsing URL or unhandled error doing .well-known discovery: Error: "Invalid homeserver discovery response"

However, sometimes later I will be able to log in with Firefox in the normal window (not using "Private Window" mode). It seems to me that some kind of CORS response caching has to expire before that is possible. I can't properly reproduce a successful login, though, as even after a whole night the login error can still persist.

There is certainly no CORS issue as Firefox logins in the Private Window, and also in Chrome, work without any issues using the exact same login data. I rather think that this must be due to some error about restoring the Firefox session.

Finally, this is not the first time we had login issues with Riot / Matrix in our organization. It's really frustrating for people and makes me want to give up on using it further. Just to say, even if a login issue seems to be an edge case I think it's important to really track it down and solve it, because it means "complete failure" for anyone who cannot get past the login screen.

[t3chguy]

Riot being a browser app has no control over CORS nor any caches. Browsers keep those controls to themselves

[tanius]

I know. There is clearly a difference in how Firefox and Chrome go about this, and there might even be a bug in how Firefox does it when restoring a session. But until that is found and fixed (if ever) it will be a good idea to do things a bit differently in Riot to not trigger that Firefox issue.

[jryans]

What version of Riot? What version of Synapse?

[tanius]

Synapse has been installed via its Ubuntu 16.04 package:

dpkg -s matrix-synapse-py3
[…]
Version: 1.5.1+xenial1

Riot is launched directly via https://riot.im/app/ . Currently it says:

riot-web version: 1.5.7

Actually, here's our Matrix homeserver URL so you can try yourselves: https://matrix.edgeryders.eu:8448

When entering any username that is supposedly hosted on that server, such as @example:edgeryders.eu , into the riot.im login form at https://riot.im/app/#/login is that the line "Sign in to your Matrix account on matrix.org" changes to "Sign in to your Matrix account on edgeryders.eu" due to the .well-known discovery mechanism. That works as expected in Chrome and in a Firefox Private Window. (It does not need an actual account, so you can try.)

I can't see the CORS pre-flight requests in either the Firefox Private Window or normal Firefox window, so I think they are just not shown in the "Network" tab of the Firefox developer tools (?).

For reference, I set the CORS headers for https://edgeryders.eu/.well-known/matrix/client as follows in the Apache vhost section. These are the same access control headers I observed in use at https://matrix-client.matrix.org/.

# Set CORS headers to allow the Matrix Riot client to connect via cross-origin 
# requests to get the /.well-known/matrix/client file for detecting the Matrix server 
# name. Since Discourse also configures CORS and needs that, we must not 
# overwrite the CORS headers provided by Discourse. To detect if Discourse is 
# serving this request or not, we look at the "Origin:" header. Source: Adapted from 
# https://stackoverflow.com/a/47383394 , https://stackoverflow.com/a/23998863
# 
SetEnvIf Origin "^(https://riot.im)$" ORIGIN_DOMAIN=$1
Header set Access-Control-Allow-Origin "%{ORIGIN_DOMAIN}e" env=ORIGIN_DOMAIN
Header set Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" env=ORIGIN_DOMAIN
Header set Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization" env=ORIGIN_DOMAIN

[tanius]

Ok, sorry folks. Wrong alarm.

It turns out the reason was rather this:

• I had the Privacy Badger Firefox extension installed.

• Privacy Badger estimated that our Matrix server and the domain used for our Matrix account IDs is a tracker and blocked all requests to it.

• Unlike in Chrome where the console will notify that a request was blocked by an extension, Firefox shows this bogus and misleading CORS error message.

This is easily fixed by manually unblocking the affected domains in Privacy Badger. I am not long enough back on Firefox to know about these subtle differences of how extensions block requests …

So, closing now. Hope it helps somebody in the future with the same issue …

[tacerus]

@tanius Thank you a lot! Privacy Badger was always showing "No trackers blocked", so it seemed like it was not taking action on the site. Element was mostly working, just very slow and occasionally it took several retries to join a room, with some not being joinable at all. Upon investigating I noticed the CORS errors in the browser console, but it took me quite a lot of searching to find this, apparently one and only, post in relation to Element Web with the same error. And turns out you are right! Disabling Privacy Badger for the site improved the performance and reliability immediately. Again, thank you, and bummer for Firefox not stating things more clearly in the console. Maybe we should open a bug report with Mozilla?

[tanius]

Maybe we should open a bug report with Mozilla?

Good idea; their error messages should really be more clear in case extensions block a request. Please go ahead and report!

I had only reported this behavior to Privacy Badger, but apparently they did not change anything in their block lists so far. There is an option in their interface "Did Privacy Badger break this site? Let us know!" If everyone coming here due to this issue uses that option, we can hope that Privacy Badger devs will react.