Yesterday, per the extended discussion on bug 40124, gerrit change I5f9ba5b0 has been
merged. It extends the action=options API, essentially allowing user scripts, gadgets, and
external editors to store arbitrary persistent private data in user preferences. [
https://bugzilla.wikimedia.org/40124 /
https://gerrit.wikimedia.org/r/#q,I5f9ba5b0,n,z ]
This officially reenables the feature that was present, but undocumented and defective in
MW 1.20 (saving preferences using Special:Preferences cleared any additional fields) and
which has been disabled in 1.20.1 as a part of a security fix (bug 42202 / gerrit
I98df55f2). [
https://bugzilla.wikimedia.org/42202 /
https://gerrit.wikimedia.org/r/#q,I98df55f2,n,z ]
These semi-arbitrary options have only three limitations imposed on them:
* the key must start with userjs- prefix (to avoid conflicting with new options being
added in core or in extensions)
* the length of the key must not exceed 255 bytes (this is a database schema limitation)
* the key must consist only of ASCII letters, numbers, hyphens and underscores (a-z, A-Z,
0-9, _, -; for sanity)
There are currently no hard limits on the length nor contents of the value, as well as on
the number of additional preferences. The contents of these preferences are not escaped,
sanitized nor validated in any way; script authors are expected to sanitize them
themselves to prevent XSS attacks and other security vulnerabilities. Similar care should
be taken if they are ever shown anywhere in the Special:Preferences interface.
Two low-severity sister issues are left to be solved right now:
* bug 43959 - action=options API should allow resetting of chosen preferences (instead of
the all-or-nothing approach)
* bug 43960 - Arbitrary userjs- preferences should be shown in the GUI, with the
possibility of clearing them one-by-one
[
https://bugzilla.wikimedia.org/43959 /
https://bugzilla.wikimedia.org/43960 ]
Overall, this could be a replacement for the current system of storing settings as global
variables set in user's skin.js file, or in a separate .js file with gadget
configuration, or in cookies / localStorage, which all have their drawbacks (clumsy,
non-private, force an edit on-wiki to change prefs, volatile, possibly size-limited...).
I'm quite looking forward to this happening :)
--
Matma Rex