About the two sister issues that are still open (bug 43959 and 43960),
unless somebody beats me to it, I will work on resolving those sometime
tonight or tomorrow night.
Additionally, one thing we might want to change is at the very least doing
a quick length check on userjs- options just to make sure they fit in the
database, although it shouldn't really be an issue. :P
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
| tylerromeo(a)gmail.com
On Mon, Jan 14, 2013 at 9:38 AM, Matma Rex <matma.rex(a)gmail.com> wrote:
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://bugzilla.wikimedia.org/40124> /
https://gerrit.wikimedia.org/**r/#q,I5f9ba5b0,n,z<https://gerrit.wikimed…]
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://bugzilla.wikimedia.org/42…
https://gerrit.wikimedia.org/**r/#q,I98df55f2,n,z<https://gerrit.wikimed…]
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/43…
https://bugzilla.wikimedia.**org/43960<https://bugzilla.wikimedia.org/43…]
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
______________________________**_________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.…