Last modified: 2011-03-13 18:06:29 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 15081 - Create new system message to allow admins to add HTML to head section
Create new system message to allow admins to add HTML to head section
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2008-08-07 22:01 UTC by Bawolff (Brian Wolff)
Modified: 2011-03-13 18:06 UTC (History)
4 users (show)

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


Description Bawolff (Brian Wolff) 2008-08-07 22:01:45 UTC
This is a feature request to add a new mediawiki interface message page (ex [[mediawiki:headhtml]]) that inserts html somewhere between the <head> and </head> tags of a page.

The rationale for this is sometimes the community may wish to add tags in the headers of all pages. For example, on the english wikinews, we use a javascript hack to add:

<link title="Lastest News (RSS)" rel="alternate" href="" type="application/rss+xml"/>

To the head. This could be much better accomplished by adding it to some system interface message somewhere, as the current system (wikinews uses) does not work with non-js browsers. (not to mention the icky feeling inside from using javascript to do such a thing)

I don't believe this would add any additional security risks, as admins can already do quite a lot via the [[mediawiki:common.js]] and other messages that allow raw html.

Thanks for your consideration,
Comment 1 Daniel Friesen 2008-08-08 16:32:23 UTC
For some time we've been trying to move AWAY from any html being possible to include into the page. IMHO this is a step in the exact opposite direction.

These kind of additions are best left to extensions which already have proper ability to add links and other things to the head.

Oh, and yes it is a major security risk. JS is one thing, but allowing raw html in the header.

<meta http-equiv="refresh" content="1," />

Then they could run a near exact copy of Wikipedia on the other site (fool users into thinking they are still on Wikipedia), and trick anyone into logging into the wiki, which could easily have a hacked login form that saves the password and then redirects back to Wikipedia.

Adding raw html is FAR more dangerous than allowing JS. Unlike JS, most browsers don't have an option to disable meta redirects. In fact, I only have that ability in FireFox because of the web developer toolbar.

Recommend WONTFIX.
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-08 16:47:12 UTC
It's not "far" more dangerous, it's just slightly more dangerous.  It only protects people with JavaScript off, which is not many people.  If JS is on, there's nothing important you can do with raw HTML editing that you can't do with JS.  Except that it's more friendly to those with JS off, which is a plus.

We're moving away from having raw HTML in ordinary messages, but that's more for sanitization and privilege compartmentalization (e.g., a separate editjs right) than for security in a standard configuration.

That said, the specific request was serviced by introduction of a new config setting, I believe.  Are there other proposed uses?
Comment 3 Daniel Friesen 2008-08-08 16:56:52 UTC
For a JS window.location = ... an administrator can disable JS then go and edit the JS message to remove it.

But for a meta tag. Disabling JS won't help at all. The administrator will have to hunt down an extension or other browser which is not affected by meta redirects just to remove it.

In fact, the number of people who can deal with a meta redirect is likely lower than those who can deal with a js redirect. The latter is fairly common, but to many admins the former may be quite unexpected.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-08 17:17:34 UTC
If an admin is maliciously disabling the site, there are probably a number of other ways to do that.  But I do take the point that this way is somewhat harder to fix.  I can't really say more unless someone can come up with use cases that actually need this level of control for admins.
Comment 5 Chad H. 2008-08-08 17:22:46 UTC
Provided the new $wgOverrideSiteFeed makes it past code review and goes live, it removes the use stated in this bug request. I'd want to see others before going forward. Lacking those, I'd second the call for WONTFIX.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-08 17:32:56 UTC
Okay, marking WONTFIX until more suggested applications surface.

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