Topic on Talk:Requests for comment/API roadmap

Currently, web applications using client-side JavaScript can only access our API via JSONP (wrapped in a function call and run through a <script> tag). This is a bit nasty for several reasons:

• different URLs -> breaks potential shared caching with other apps that use the same queries over JSON
• harder to get progress feedback or detect errors
• can't do POST requests at all
• authentication is disabled to prevent CSRF stealing a web user's credentials

This has practical limitations for some mobile platforms as well -- for instance our Wikipedia app for Firefox OS is a web app hosted on bits.wikimedia.org. Since an XHR can't access *.wikipedia.org/w/api.php from there, it has to use either JSONP or a server-side proxy (icky, hides IPs, no load balancing, etc). Since a proxy is icky and hard to scale, we're using JSONP for now... but this won't work once we try to add login and editing features, since auth isn't available.

If we had CORS headers set up to allow non-authenticated (no cookies) access via XHR from all third-party domains, and we could auth without cookies (can we use a token for this? I .... think so) that would be helpful.

Not sure if that's doable on the current API or not. :D

There is some sort of CORS handling in the API, but I will need to look further into it to get a better understanding of how it is setup.

Basically, it's three parts:

• The client adds an "origin" parameter to the request to indicate the origin and explicitly request CORS.
• The browser adds an "Origin" HTTP header, to also indicate the origin.
• The MediaWiki configuration has $wgCrossSiteAJAXdomains and $wgCrossSiteAJAXdomainExceptions to determine whether to allow the cross-domain request.

First, the "origin" parameter must match one of the values in the "Origin" header, or the request fails.

Second, the "origin" parameter must match one of the patterns in $wgCrossSiteAJAXdomains and not match any pattern in $wgCrossSiteAJAXdomainExceptions. These are currently set to allow various WMF wikis (but bits.wikimedia.org is not in the list).

If both checks pass, then the appropriate CORS headers are returned to instruct the browser to allow the request, including cookies.

I guess the basic idea behind this proposed non-cookie authentication method would be that it works just like cookies except that it's handled by the client code rather than the browser?

Yeah, it would be nice to drop JSONP for CORS. We'll have to disable anonymous editing over CORS though so that the API can't be turned into a kind of mass spam attack that could come from absolutely any innocent IP in the world without people's knowledge.

For auth via tokens. This would basically be where OAuth (or ;) something like OAuth) would fit in.

Technically speaking, I think anonymous editing via action=edit already allows that kind of attack. *cough*

*facepalm* right it can, and I had a private bug about fixing that.