Page MenuHomePhabricator

CORS policy errors with any user script that calls a different subdomain's API
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Use any user script that calls the API of a different domain to current (e.g. meta.wikimedia.org while on de.wikibooks.org), for example using XReport or TwinkleGlobal

What happens?:
CORS policy rejects the API call.

What should have happened instead?:
The API call should have gone through.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
Console error

Benutzer:TanyaLlanas976#:1 Access to XMLHttpRequest at 'https://meta.wikimedia.org/w/api.php?action=query&format=json&origin=https%3A%2F%2Fde.wikibooks.org&centralauthtoken={centralauthtoken}&prop=revisions&formatversion=2&rvprop=content&rvslots=main&rvlimit=1&titles=Steward%20requests%2FGlobal' from origin 'https://de.wikibooks.org' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
meta.wikimedia.org/w/api.php?action=query&format=json&origin=https%3A%2F%2Fde.wikibooks.org&centralauthtoken={centralauthtoken}&prop=revisions&formatversion=2&rvprop=content&rvslots=main&rvlimit=1&titles=Steward%20requests%2FGlobal:1  Failed to load resource: net::ERR_FAILED

Event Timeline

I'm doubtful this is related to the recent changes around enforcing CSP. The error message seems to indicate it is more about preflight requests interacting with certain Access-Control-Allow-Origin headers.

Can you provide more detailed steps to reproduce?

This works for me when I run it in the browser console on https://de.wikibooks.org/wiki/Hauptseite, logged in as well as logged out:

await mw.loader.using('mediawiki.ForeignApi');
await new mw.ForeignApi('https://meta.wikimedia.org/w/api.php').get({});

Perhaps you are being affected by the new global rate limits (https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/LC67SXEJMMUWIFPLRTJ7WBTNZ3SEQXW4/). You may be able to view the responses in browser developer tools to confirm that. If so, this would be the same problem as T418969 (in progress).

I am now on a worse connection than before (public WiFi) and can reproduce the problem using my snippet above.

The response body for the OPTIONS request is:

You are making too many requests.
Please reduce your request rate or contact <bot-traffic@wikimedia.org>.

Hopefully we can find out what's causing it.

Hopefully we can find out what's causing it.

That specific error is coming from api-gateway, so indeed seems to be related if not the same as T418969.

If it was due to T418969, the rate-limited response body should be a JSON object, so this might be yet another, different rate limit.

If it was due to T418969, the rate-limited response body should be a JSON object, so this might be yet another, different rate limit.

The Envoy gateway sends a plain text response. This is indeed related. There is a patch up already, but it combines "no rate limit for OPTIONS" with more complex cors related hresponse manipulation. I'll split that out so we can deploy it asap.

See https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1248461/8/charts/api-gateway/lua/restgateway.lua#79

Change #1251289 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[operations/deployment-charts@master] rest-gateway: do not limit pre-flight requests

https://gerrit.wikimedia.org/r/1251289

Change #1251289 merged by jenkins-bot:

[operations/deployment-charts@master] rest-gateway: do not limit pre-flight requests

https://gerrit.wikimedia.org/r/1251289

We have removed the rate limits on OPTIONS requests and I don't see anymore 429 responses to them in logs. Resolving, please feel free to reopen if the issue presents itself again.