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 | tylerro...@gmail.com On Mon, Jan 14, 2013 at 9:38 AM, Matma Rex <matma....@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.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://bugzilla.wikimedia.org/42202>/ > https://gerrit.wikimedia.org/**r/#q,I98df55f2,n,z<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/43959>/ > https://bugzilla.wikimedia.**org/43960<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 > > ______________________________**_________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
