Last modified: 2011-03-13 18:06:29 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="http://feeds.feedburner.com/WikinewsLatestNews" 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, -[[n:user:Bawolff]]
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,http://en.wikipedla.org/" /> 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.
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?
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.
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.
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.
Okay, marking WONTFIX until more suggested applications surface.
