*Apologies for the cross-posting*
A quick reminder that we are looking for proposals for presentations at the
upcoming EMWCon - March 8-10 in McLean, Virginia, USA.
The deadline for proposals is Tuesday, 21 February.
Feel free to edit the event page on Mediawiki.org with your proposal.
You can also email me if you have any questions on an idea you might have.
To get the mental gears going, here are a few topic suggesions:
* Examples of use of MediaWiki in your organization
* Lessons learned and challenges in the use of MediaWiki and MediaWiki
extensions in organizations
* Gamification and other incentives for wiki contributions
* Wikitext patterns and wiki design patterns
* Wiki development frameworks
* MediaWiki extension usage and development
* New extensions, extension updates, and ideas for future extensions
Thanks again, and we look forward to seeing you at EMWCon in less than a
---------- Forwarded message ----------
From: Brian Wolff <bawolff(a)gmail.com>
Date: Tue, Jan 31, 2017 at 4:02 PM
Subject: [Wikitech-l] Proposal: Make $wgRawHTML not apply to system messages
To: wikitech-l <wikitech-l(a)lists.wikimedia.org>
Most of the time we assume that writing code like:
wfMessage( 'foo' )->params( $this->getRequest()->getVal( 'bar' ) )->parse();
is totally safe. However, in a wiki with $wgRawHTML = true; this code
would be an XSS. I've looked through core, and couldn't find any
examples of using unsanitized url parameters as a message parameter in
a parsed message, however it seems to me like this sort of thing is an
accident waiting to happen.
I would like to propose that $wgRawHTML only apply to actual pages.
The <html> parser tag should not be active in wfMessage() or other
parser contexts. I don't think this would break anything, but I'd like
feedback on if anyone could think of anything this could break.
For more information see https://phabricator.wikimedia.org/T156184 .
Please post any feedback about this idea on that bug.
Wikitech-l mailing list