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 :)
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 www.whizkidztech.com | tylerromeo@gmail.com
On Mon, Jan 14, 2013 at 9:38 AM, Matma Rex matma.rex@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,zhttps://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/42202https://bugzilla.wikimedia.org/42202/ https://gerrit.wikimedia.org/**r/#q,I98df55f2,n,zhttps://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/43959https://bugzilla.wikimedia.org/43959/ https://bugzilla.wikimedia.**org/43960https://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
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, 14 Jan 2013 15:42:35 +0100, Tyler Romeo tylerromeo@gmail.com wrote:
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.
Thanks!
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.
Well, these fields are BLOBs, so any length should work as long as you have enough disk space. ;) The length of the key (which is a VARBINARY(255)) is checked.
On Mon, Jan 14, 2013 at 9:49 AM, Matma Rex matma.rex@gmail.com wrote:
On Mon, 14 Jan 2013 15:42:35 +0100, Tyler Romeo tylerromeo@gmail.com wrote:
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.
Well, these fields are BLOBs, so any length should work as long as you have enough disk space. ;) The length of the key (which is a VARBINARY(255)) is checked.
Not true, a BLOB can hold 65535 bytes maximum. That's short enough that it probably is worth adding a length check to the API.
See https://dev.mysql.com/doc/refman/5.0/en//blob.html for details.
On Mon, 14 Jan 2013 17:48:32 +0100, Brad Jorsch bjorsch@wikimedia.org wrote:
On Mon, Jan 14, 2013 at 9:49 AM, Matma Rex matma.rex@gmail.com wrote:
Well, these fields are BLOBs, so any length should work as long as you have enough disk space. ;) The length of the key (which is a VARBINARY(255)) is checked.
Not true, a BLOB can hold 65535 bytes maximum. That's short enough that it probably is worth adding a length check to the API.
Huh. I guess I was under the mistaken impression that MySQL is reasonable. Thanks for the clarification.
(I just checked the default size limits for similar fields on SQLite and Postresql: 1 gigabyte for both. Yay for MySQL.)
wikitech-l@lists.wikimedia.org