Last modified: 2014-11-17 10:36:43 UTC
At the moment, you can change the preferences from each page with javascript: $.post( '/wiki/Special:Preferences', { 'wpEditToken': mw.user.tokens.get('editToken'), 'wprcdays': 21 } ); Is this intended? Maybe it is better to use an own token for Preferences and not the edit token, to avoid this. Please close as WONTFIX, when all is right. Thanks.
A little while ago when the idea for a writable preferences api came up, the subject was raised that we don't want JavaScript gadgets to be able to mess with preferences. Looks like it already could. I'd assume this is not intended and should not be relied on.
A separate token for preferences would be readable by $.get('/wiki/Special:Preferences')
A possibility to prevent unwanted changes of the preferences is to force solving a [[CAPTCHA]] for every change.
Hm.. yeah, at first I don't see another solution.
A possibility prevent reading a special preferences token by an other page is to move the preferences page out of the [[same origin policy]].
Yeah, the thing is though we probably still the ability (in the future) to configure certain things from a script. However that's what APIs are for. One can send cross-domain requests from JS, just not read/receive them. So if we would move it out of the same-origin, machines can still make requests to it and the other end would then detect the missing token and ask for human confirmation in a visual way. I like it, although it's hard to realize since most MediaWiki wikis only have 1 domain.
Lowering priority and milestone. This is a valid issue but not something of great concern right now. Scripts can access it, yes. But only when executed from the wiki-domain, and on the wiki-domain only scripts that the user trusted are executed.
Since Bug 18195 it is also possible to change the preferences via API.
