Page MenuHomeMiraheze

Continuous JavaScript errors with Echo and GlobalWatchlist: Access to XMLHttpRequest blocked by CORS policy
Open, NormalPublic


Access to XMLHttpRequest at '' from origin '' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribu

The above error appears in JavaScript console when trying to use GlobalWatchlist extension (installed yesterday) to access watchlists from other wikis. However the extent of the issue seems a bit larger, which is why I'm creating this task. The error appears for me 187 times and infinitly increasing every time Echo is expanded on the wiki, when global Echo notifications are enabled. After opening and closing the Echo notification dialogue a couple of times, my JavaScript errors reached over 8,000 with that error appearing repeatedly about multiple wikis. I do think this should be investigated. I talked to @Reception123 and @Paladox on Discord, neither of whom know what's causing the issue or how to resolve it.

Event Timeline

Universal_Omega created this task.

What browser are you using?

In T7311#145512, @R4356th wrote:

What browser are you using?

Chrome, Firefox, Edge, 2 devices same issue.

If you want to allow credentials then your Access-Control-Allow-Origin must not use *. You will have to specify the exact protocol + domain + port.

That's our issue, we need to somehow change it to not be * it seems. (At least for specific requests)/possibly just metawiki and loginwiki need to specify something other then *, although I'm not certain.

Is it possible/safe to completely disable the CORS header on just a single page on loginwiki? (Special:GlobalWatchlist)

I would think that would be OK because 1) it is a special page so nothing bad should be injectable there, and 2) no one could edit JS, etc there to inject anything from bad websites. That's the only solution I can really think of actually.

If this is unfeasible then this task can be closed as declined as I see no other way to do it then doing that possibly.

I think we should consider configuring CORS. Configuring $wgCrossSiteAJAXdomains to allow * would be a valid solution to this problem, but it could raise other issues.

The first of which is that any wiki on * would be able to make requests across for other sites. For example, a script on could be used to make a request on to add someone to the local Consul group, while simultaneously sending a request to to add someone to the global Steward group. I would not recommend we go this route unless we can have an option for stewards and other globally privileged accounts to be able to prevent the loading of user and site scripts for untrusted wikis (I'd like to see this anyway).

Second, if custom domains are generating authenticated CORS requests, we'd have to add them all to this config, and remove them immediately if the domain appears to be insecure.

Allowing only and would seem to be the best option, at least for now, but does limit potentially valid CORS requests from other wikis.