In the beginning, there was Article.php. And the Article class had methods
like Article::view(), Article::delete(), Article::protect(), etc. And the
fundamental codeflow of Mediawiki consisted of something along the lines of:
$article = new Article( $title );
$action = wfGetTheActionSomehow();
$article->$action();
Over time Article has grown and bloated to become our third largest class
(after ZhConversion and Parser). Several of its action methods have been
spun out to separate files (EditPage.php, ProtectionForm.php and
HistoryPage.php, among others). It's long overdue that this process be
carried through to its natural conclusion with all action methods spun out
into some new structure.
There are essentially two competing possibilities for structuring this, and
they reflect the two parallel systems we have for "doing things other than
viewing" to a wiki. One is action parameters, and the other is special
pages. We have action=edit, or Special:MovePage, for instance; they have a
similar function but different structure. We have action=delete to get rid
of stuff, but then Special:Undelete to bring it back again.
Special:Whatlinkshere and action=history are another pair of pages which
have very similar principles (getting data that relates to a given page) but
different implementations.
For either case in the backend I would think we'd want to create an
ActionPage base class and an EditActionPage from that, which looks
internally rather like a SpecialPage construct, might even subclass it. I'd
like to ask people's opinions about which they think would work better in
the frontend for, say, editing or protecting. If people think it would be
better as a special page we'd make
http://foo.example.com/w/index.php?title=Bar&action=edit a hard redirect to
Special:Edit/Bar; that has the significant advantage of being able to be
formed as an internal link. Conversely if we'd like to keep it an action it
would make sense to redirect Special:MovePage/Bar back to
?title=Bar&action=move. Or is something more exotic like
[[Action:Edit/Bar]] a possibility?
Thoughts?
--HM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I would like to announce the release of MediaWiki 1.16.3, which is a
security release. Three security issues were discovered.
Masato Kinugawa discovered a cross-site scripting (XSS) issue, which
affects Internet Explorer clients only, and only version 6 and
earlier. Web server configuration changes are required to fix this
issue. Upgrading MediaWiki will only be sufficient for people who use
Apache with AllowOverride enabled.
Due to the diversity of uploaded files that we allow, MediaWiki does
not guarantee that uploaded files will be safe if they are interpreted
by the client as some arbitrary file type, such as HTML. We rely on
the web server to send the correct Content-Type header, and we rely on
the web browser to respect it. This XSS issue arises due to IE 6
looking for a file extension in the query string of the URL (i.e.
after the "?"), if no extension is found in path part of the URL.
Masato Kinugawa discovered that the file extension in the path part
can be hidden from IE 6 by substituting the "." with "%2E".
To fix this issue, configure your web server to deny requests with
URLs that have a path part ending in a dot followed by a dangerous
file extension. For example, in Apache with mod_rewrite:
RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z]{1,4}$ [nocase]
RewriteRule . - [forbidden]
Upgrading MediaWiki is necessary to fix this issue in
dynamically-generated content. This issue is easier to exploit using
dynamically generated content, since it requires no special
privileges. Accounts on both public and private wikis can be
compromised by clicking a malicious link in an email or website. For
more details, see bug 28235.
Wikipedia user Suffusion of Yellow discovered a CSS validation error
in the wikitext parser. This is an XSS issue for Internet Explorer
clients, and a privacy loss issue for other clients since it allows
the embedding of arbitrary remote images. For more details, see bug 28450.
MediaWiki developer Happy-Melon discovered that the transwiki import
feature neglected to perform access control checks on form submission.
The transwiki import feature is disabled by default. If it is enabled,
it allows wiki pages to be copied from a remote wiki listed in
$wgImportSources. The issue means that any user can trigger such an
import to occur. For more details, see bug 28449.
The localisations were updated using content from translatewiki.net.
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz
Patch to previous version (1.16.2), without interface text:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAk2jxbAACgkQgkA+Wfn4zXn38gCWISDEZuC+Ap3Z4aBfibnuNSU1
EgCfeL2lo/4XtCuoKOwah0YbuaHyf5I=
=S2JZ
-----END PGP SIGNATURE-----
库ukulm仍啊空说八宝山的人飞蛾
原信息
主题： [Wikitech-l] MediaWiki security release 1.16.3
发件人： Tim Starling <tstarling(a)wikimedia.org>
日期： 2011/04/12 11:24
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I would like to announce the release of MediaWiki 1.16.3, which is a
security release. Three security issues were discovered.
Masato Kinugawa discovered a cross-site scripting (XSS) issue, which
affects Internet Explorer clients only, and only version 6 and
earlier. Web server configuration changes are required to fix this
issue. Upgrading MediaWiki will only be sufficient for people who use
Apache with AllowOverride enabled.
Due to the diversity of uploaded files that we allow, MediaWiki does
not guarantee that uploaded files will be safe if they are interpreted
by the client as some arbitrary file type, such as HTML. We rely on
the web server to send the correct Content-Type header, and we rely on
the web browser to respect it. This XSS issue arises due to IE 6
looking for a file extension in the query string of the URL (i.e.
after the "?"), if no extension is found in path part of the URL.
Masato Kinugawa discovered that the file extension in the path part
can be hidden from IE 6 by substituting the "." with "%2E".
To fix this issue, configure your web server to deny requests with
URLs that have a path part ending in a dot followed by a dangerous
file extension. For example, in Apache with mod_rewrite:
RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z]{1,4}$ [nocase]
RewriteRule . - [forbidden]
Upgrading MediaWiki is necessary to fix this issue in
dynamically-generated content. This issue is easier to exploit using
dynamically generated content, since it requires no special
privileges. Accounts on both public and private wikis can be
compromised by clicking a malicious link in an email or website. For
more details, see bug 28235.
Wikipedia user Suffusion of Yellow discovered a CSS validation error
in the wikitext parser. This is an XSS issue for Internet Explorer
clients, and a privacy loss issue for other clients since it allows
the embedding of arbitrary remote images. For more details, see bug 28450.
MediaWiki developer Happy-Melon discovered that the transwiki import
feature neglected to perform access control checks on form submission.
The transwiki import feature is disabled by default. If it is enabled,
it allows wiki pages to be copied from a remote wiki listed in
$wgImportSources. The issue means that any user can trigger such an
import to occur. For more details, see bug 28449.
The localisations were updated using content from translatewiki.net.
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz
Patch to previous version (1.16.2), without interface text:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.3.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.3.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAk2jxbAACgkQgkA+Wfn4zXn38gCWISDEZuC+Ap3Z4aBfibnuNSU1
EgCfeL2lo/4XtCuoKOwah0YbuaHyf5I=
=S2JZ
-----END PGP SIGNATURE-----
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'd like to know something more about template parsing/caching for
performance issues.
My question is: when a template is called, it's wikicode, I suppose, is
parsed and translated into "something running" - I can't imagine what
precisely, but I don't care so much about (so far :-) ). If a second call
comes to the server for the same template, but with different parameters,
the template is parsed again from scratch or something from previous parsing
is used again, so saving a little bit of server load?
If the reply is "yes", t.i. if the "running code" of the whole template is
somehow saved and cached, ready to be used again with new parameters,
perhaps it could be a good idea to build templates as "librares of different
templates", using the name of the template as a "library name" and a
parameter as the name of "specific function"; a simple #switch could be used
to use the appropriate code of that "specific function".
On the contrary, if nothing is saved, there would be good reasons to keep
the template code as simple as possible, and this idea of "libraries" would
be a bad one.
Alex
On 11-04-08 09:49 AM, Henny Savenije wrote:
> At 12:45 AM 4/9/2011, Trevor wrote:
>> Take a look at the Vector extension. It offers a variety of
>> progressive enhancements for the Vector skin.
> I tried to install that but I get a blank page.
> _ _
> (o) (o)
> oOOO----(_)----OOOo---
> Henny (Lee Hae Kang)
By any chance are you running 1.16?
The Vector extension is only compatible with 1.17+. For 1.16 you need to
use the UsabilityInitiative extension that the Vector extension was
split out from around 1.17.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
I've taken the liberty of moving most of the math guts out of MediaWiki core
into its own Math extension:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14202http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85706
We meant to do this years ago -- I even got partway through it once but got
held up on the horrid Special:Preferences system we had back in the day and
never finished it. The modern Preferences class is a lot more flexible, and
I was able to just grab the function that sets up that portion of the form
and move it over. Yay!
There are a few cleanup bits still to do; I didn't want to dive into the
message files just yet. There are some legacy interfaces on Language for
getting the math option names, so that'll need a little more fixin' to
remove those (the strings _should_ all be in the regular message area now)
and then break the message files out.
People doing third-party packages of MediaWiki should take note: the texvc
subprogram source will live in the extension now, not core, so build scripts
for 'mediawiki-math' packages will need to be updated.
-- brion
When Roan Kattouw reviewed, and then rewrote most of the Narayam extension, I reviewed his code, and found many things about the user interface that could be, and need to be improved. I have both some observations and some suggestions, expressed in the attached PDF.
The exact design I'm proposing isn't a requirement, but hopefully is provides a starting point for a way to get this extension's user interface where we need it to be.
- Trevor
Hi all!
Wikimedia Deutschland is offering a contract for implementing the GraphServ
component for our Graph Processor project. Anyone interested is invited to
apply, the official call for bids is at
<http://wikimedia.de/wiki/Ausschreibung/GraphServ>.
The Graph Processor project aims to develop an infrastructure for rapidly
analyzing and evaluating Wikipedia's category structure. It's supposed to become
part of the Toolserver infrastructure (and eventually, the WMF search cluster)
that allows CatScan-like queries to run in under a second instead of minutes.
The contract offered here covers the implementation of the GraphServ component,
which is to function as a service by which applications can access the category
structures of different wikis, similar to the way a database server would
provide access to information stored in databases. Technically, GraphServ is a
server that manages TCP connections and attaches them to instances of GraphCore,
which do the actual processing of the category structures
<https://github.com/jkroll20/graphcore/blob/master/spec.rst>. The server will be
accessed by applications via client libraries written in PHP, Python, etc, which
are not in scope of the contract but will be developed in parallel by Wikimedia
Deutschland.
A rough specification of the GraphServ component along with requirements for the
implementations can be found at
<http://wikimedia.de/wiki/Ausschreibung/GraphServ/Spec>.
Note that GraphServ will be released as Open Source Software. While Wikimedia
Deutschland will be the copyright holder for the software developed under
contract, we will include the name of the actual authors in the copyright notice.
Applications should include the following:
* The applicant's prior experience with designing and implementing client/server
software, as well as any other relevant qualifications
* An overview of the intended architecture of the implementation and the
technologies used, along with a rationale for choosing this architecture and
technologies over others.
* A rough road map of the implementation, documentation and testing phases, with
the appropriate mile stones.
* Estimate of working hours needed
* Time frame for the implementation (calendar weeks)
* Total expected cost, including taxes
Please send your application to <technik(a)wikimedia.de> by April 29.
Cheers,
Daniel
PS: please forward this to anyone you think could be interested. thanks!
Starting with this coming Monday's bug triage, I want to try and make
sure the community's voice is heard. In order to do that, I've created
the “triage” keyword in Bugzilla. Every week, I'll announce a theme and
use this keyword to keep track of the bugs that will be handled in the
meeting.
As we discuss the bug, it will be modified, probably assigned to a
developer, and the “triage” keyword removed. Some people may see this
as bug-spam, but I'd like to keep the email notifications on so that
people who have expressed an interest will know that we're giving the
bugs some love.
This week, I'm going to focus on Parser-related bugs. There are
currently 10 bugs on the with the “triage” keyword applied. A bug
triage meeting needs about 30 bugs, so I have room for about 20 more
right now. I'll be adding to the list before Monday, but this is your
chance to get WMF's developers talking about YOUR favorite parser bug by
adding the “triage” keyword.
I will reserve the right to remove the “triage” keyword — especially if
the list becomes unwieldy, or if the bug has nothing to do with parsing
— but I wanted to start to open up the triage process a bit more and
begin to provide a way for the community to participate in these
meetings.
Mark.