Page MenuHomePhabricator

Allow cross-site domain access from (tools) Labs via CORS
Closed, ResolvedPublic


Labs, or at least Tools Labs, should be added to the CORS list. That would allow, amongst other things, for the retrieval of cached Wikidata objects, like this:
(which redirects to )

Right now, any JavaScript on Labs needs to query the API via JSONP, which means Apache hit, PHP running, DB or object store access etc.

This would reduce the load on the servers, and speed up the access to Wikidata objects (unless done in huge numbers).

I would prefer CORS to be enabled for all of the Wikimediaverse, not just the Wikidata URL(s), for a few other tools.

According to bug T62835 Labs should be added to $wgCrossSiteAJAXdomains, apparently.



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:15 AM
bzimport set Reference to bz63808.
bzimport added a subscriber: Unknown Object (MLST).
JanZerebecki added a project: Wikidata.
JanZerebecki set Security to None.
hoo claimed this task.
hoo added a subscriber: hoo.

CORS for all of Wikimedia (or all of Wikidata) from labs is obviously not going to happen (due to security concerns probably outlined somewhere else). Allowing access from all origins on Special:EntityData has been done with fc7dff5596735795af02763f81e42a3167eff9d8.

Jdlrobson added a subscriber: csteipp.

I talked to @csteipp and apparently there is a bug somewhere about allowing CORS requests from any domain (but anonymous requests only) which makes complete sense as the security issues do not apply.

Reopening on the basis that from @Magnus example this seems to be what he's asked for and would suit him nicely (and one of my current use cases). @csteipp feel free to merge this into that task or at least link to it. @Magnus if you are hoping to do requests that require authentication then I guess that's not going to happen.

FWIW, things have moved on is this particular battleground. Getting a single cached item using CORS is likely still faster than via API, but I have designed most of my tools to "collect" items and them retrieve them in batches of 50 from the API, which is quite fast these days, and probably offsets any speed gain of CORS by reducing the number of requests.

I definitely do not require authenticated actions via CORS for the foreseeable future. IMO this issue can be closed, I am happy with the way things work now.

I wanted to use labs for a small tool I'm working on and alas I cannot use JSONP nor do I have a @Magnus tool. I've ended up using heruko instead which is a shame :/

Krenair removed hoo as the assignee of this task.Aug 22 2015, 5:21 PM
Krenair moved this task from Backlog to External on the Wikimedia-Site-requests board.

This task may be rendered moot if "Access-Control-Allow-Origin: *" is implemented, re. T62835. Absent that, I think it would be safe to allow read-only access from labs by adding the domain(s) to the whitelist ($wgCrossSiteAJAXdomains) and setting "Access-Control-Allow-Credentials: false" on pre-flight and primary responses.

Not sure if to add this here or start a new task, but havinf CORS for Labs (or anyone) for the new pageviews API, e.g.

would be really helpful.

Not sure if to add this here or start a new task, but havinf CORS for Labs (or anyone) for the new pageviews API, e.g.

would be really helpful.

Hm... CORS is definitely enabled on that path, because the demo for the API [1] runs on a labs instance and so has to use CORS. I wonder why it's not working in your specific instance, @Magnus, do you have an actual CORS error?

[1] (line 254 if you open the dev tools to look at the source)

Update: CORS is working for the pageview API.

It looks like general labs access is being worked on in T62835, and the specific requests (wikidata, pageviews) is working. So closing this for now. Reopen if we need to keep working on those specific issues.