Last modified: 2014-09-23 23:32:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10180 - Hooks needed in Sanitizer to control acceptable tags and attributes
Hooks needed in Sanitizer to control acceptable tags and attributes
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-07 04:02 UTC by Jim R. Wilson
Modified: 2014-09-23 23:32 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
first-draft at patch to satisfy requirements (1.16 KB, patch)
2007-06-07 04:03 UTC, Jim R. Wilson
Details

Description Jim R. Wilson 2007-06-07 04:02:16 UTC
There is currently no way in MediaWiki to alter the list of acceptable HTML tags or attributes thereto.  This information is hard coded into Sanitizer.php, and loaded into static variables - making them even harder to get to and modify.

I propose new hooks to allow extensions to modify the lists of acceptable HTML tags and attributes, or at least provide alternate lists in certain circumstances.

Any solution would also have to be sensitive to the need for extensions to be able to conditionally allow or disallow certain tags or attributes based on the context of the parse.  Meaning that it is not sufficient to merely provide a window into the initial whitelist creation, but then continue to store said lists statically (unless the static allocation will be revisited as a result of extension execution).

A tentative patch will be supplied shortly.
Comment 1 Jim R. Wilson 2007-06-07 04:03:53 UTC
Created attachment 3730 [details]
first-draft at patch to satisfy requirements
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-07 04:15:44 UTC
Well, statically modifying the list would be a simple solution to a very common request (how do I allow tag X?).  It might be easiest to just make them globals, from that perspective, like other config options.  But it's pretty ugly to encourage extensions to change around globals dynamically, whether they're in the form of actual globals or static variables, and your approach (a hook run once) does avoid that.

Alternatively, we could perhaps convert the Sanitizer into an actual class of objects, not just a namespace of functions, and so allow per-instance modification of the attributes via mutators.  That would, of course, require some rearchitecturing and bunches of reverse-compatibility stuff.
Comment 3 Jim R. Wilson 2007-06-07 14:58:18 UTC
Thanks for taking a look, Simetrical.

Yeah - my first thought was also to create new globals, but then I realized that it wouldn't allow extensions to _easily_ modify the Sanitizer on a per-request basis.

Also, just a note, since my first hook passes the &$staticInitialized var as one of the hook args, it's possible to have an extension re-set this to false so that the hook gets run every time the Sanitizer is invoked (allowing the same or other extensions to apply different "what tag is allowed" in a contextual manner).

Reforamtting the Sanitizer may be a good idea - it would certainly help if more information about the Parser or ParserOptions were available to the Sanitizer at runtime (that way there'd be less hackery necessary to determine the "context" of the parse).  However, as you note, this is much more work and requires backwards compatibility tests.
Comment 4 Soroush 2007-11-09 15:11:47 UTC
(In reply to comment #1)
> Created an attachment (id=3730) [details]
> first-draft at patch to satisfy requirements
> 

Looks nicer than global variables for html tags and attributes. I think such change in sanitizer.php is required.
Comment 5 The Evil IP address 2010-10-06 13:55:53 UTC
I can completely double the request. I wanted to create some very simple like:

$htmlpairsStatic[] = 'address';
$whitelist['address'] = $common;

to allow the <address> tag in MediaWiki, but this seems to be very difficult.
Comment 6 p858snake 2011-04-30 00:10:08 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 7 Sumana Harihareswara 2011-11-09 19:06:29 UTC
Jim, I'm adding the "reviewed" keyword since you did get a review on your patch from Aryeh.

Do people still have the need that this patch would address, or have we addressed it in subsequent versions of MediaWiki?

Also, If you're interested in seeing the work that Gabriel and Brion are doing, rewriting the parser, check out the parser mailing list: https://lists.wikimedia.org/mailman/listinfo/wikitext-l

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links