On Wed, May 16, 2012 at 4:37 PM, Terry Chay tchay@wikimedia.org wrote:
- jsonp for state changing should be allowed (if it isn't already) since they require an edit token (shared secret) [QUESTION: is this prevented or is the API documentation in error? It should be allowed. The edittoken blocks XSSI and CSRF exploits already. "This means that things that require additional rights, such as rcprop=patrolled, won't work unless anonymous users are allowed to use them." I don't know what that means… rcprop=patrolled is a query=list operation. :-(]
Currently, JSONP immediately drops all privileges (i.e. treats you as an anon) and will refuse to provide any tokens. rcprop=patrolled is a query=list operation, yes, but it requires additional privileges (the right to see the patrolled-ness of changes) that typically aren't given to anons. Similarly, list=deletedrevs (shows deleted history, restricted to administrators) won't work either, and list=watchlist will give you an error message about how you need to be logged in to view your watchlist.
Dropping privileges for JSONP is needed to prevent data leaks as described above. Not providing tokens is necessary to prevent CSRF, because using tokens for CSRF protection relies on the fact that scripts cannot read (but can execute) code from another domain.
State-changing actions over JSONP are theoretically allowed, but you could only do them as an anon and you would have to hard-code the token (the token for anons is always the same), because the API won't give you one (theoretically unnecessary, because you'd get an anonymous token, but good for extra paranoia). You can't do state-changing actions as a logged-in user over JSONP because of the privilege dropping, but even if we didn't drop privileges if a valid token is provided, that token could not have been obtained using JSONP (otherwise our CSRF protection would be broken), so I don't see how that would be useful in practice.
Roan