Page MenuHomeMiraheze

Custom Access-Control-Allow-Origin
Closed, ResolvedPublic


Context: I'm trying to build an oscilloscope with MP3/OGG files using the Web Audio API.

Problem: CORS policy blocks the media from being played, so the MP3/OGG fails to load. I thought this was initially because the Access-Control-Allow-Origin was set only to the wikis themselves, but even if I upload an audio on my own wiki, CORS policy still blocks it.
I'm testing it on for now.

The apparent solution is to manually set $wgCrossSiteAJAXdomains ($wgCrossSiteAJAXdomains):

  • All of Miraheze (and maybe some Wikimedia subdomains?):
$wgCrossSiteAJAXdomains = [
  • or allow my Wiki specifically:
$wgCrossSiteAJAXdomains = [

If possible, could this be changed? Thanks :)

Event Timeline

R4356th added a subscriber: R4356th.

Static does not use MediaWiki. It might be worth tagging this with Puppet as that currently handles the CSP for wikis.

Universal_Omega added a subscriber: Southparkfan.

Needs approval from @Southparkfan to whitelist all of in CORS policy.

In T6730#132558, @Void wrote:


There's also, but I'm not sure if that needs to be touched, especially since it doesn't appear to have been updated in a long time.

Yes, that's the culprit. wants to load, but that doesn't match the regex .(gif|ico|jpg|jpeg|png|svg)$.


@Southparkfan, just to be clear you are giving the OK to whitelist all of static.miraheze.lrg, or just wav files? If just wav files that may not be 100% sufficient enough for this task, which is why I am asking for further clarification here. Thank you!

By the way, I personally will only use audio files (MP3, OGG, WAV, FLAC) for this, as I don't see need for other file types to be used in this way (maybe video files, but I'm not sure about that).

Reassign to SPF again just for the clarification I asked for above. "Access-Control-Allow-Origin: * is totally safe to add to any resource, unless that resource contains private data protected by something other than standard credentials. Standard credentials are cookies, HTTP basic auth, and TLS client certificates."

The only private content to serve off static would be content from private wikis (proxied via img_auth.php), but authentication/authorisation for private content is/will be done through Cookies ('standard credentials'). Someone streaming XML files (non-private) could become a problem, but the risk is low (likelihood: rare, impact: we can change the ACAO header at any time and deploy the change for all users within seconds).

I'd say the wildcard ACAO header for everything on is fine.