Page MenuHomePhabricator

UNIQ... exposed to anonymous users when hook "InternalParseBeforeLinks" uses specific messages
Closed, ResolvedPublic


This assumed parser bug causes UNIQ tags to remain unsubstituted, and hence to be exposed to the user. This happens when an extension hooking to "InternalParseBeforeLinks" accesses a message that contains {{SITENAME}}. I could reproduce this on MediaWiki 1.13alpha (r36226) to 1.14alpha (r38131), even without any extensions enabled. The conditions for creating this bug are complex, but it still occurs in practice (e.g. Semantic MediaWiki hooks to this place and uses messages). Its complicated conditions make it somewhat hard to track for the user.

To reproduce:

  • Edit LocalSettings.php to include the following lines:

    $wgHooks['InternalParseBeforeLinks'][] = 'causeBug'; function causeBug() { wfMsgForContent('copyrightwarning2'); return true; }

(the message 'copyrightwarning2' could be anything with {{SITENAME}} in it)

  • Create a page containing the text "<nowiki>[[Test]]</nowiki>"
  • Log out from the wiki, and purge the cache of the freshly created page (add action=purge as a parameter to the URL).

As a result, the UNIQ tag becomes visible. This does neither happen if anonymous users edit the page or preview their edits, nor if a logged in user edits or purges the page. The problem is also not present if a message without {{SITENAME}} in it is used.

The problem can be viewed at (this wiki uses the above patch to LocalSettings). The installed extensions there do not have an effect -- disabling them still leaves the bug.

Note that this is not the same as Bug 14562, but it might of course be related internally.

Version: 1.13.x
Severity: major



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:10 PM
bzimport set Reference to bz14959.
bzimport added a subscriber: Unknown Object (MLST).

On some sites, it has been found that editing the message page is required to reproduce the bug, though after that it occurred for all users (logged in or not) even without purge. This observation was made on a Windows machine, while the original bug was discovered on Linux machines running PHP "5.2.0-8+etch11 (apache2handler)" and "5.2.4-2ubuntu5.2 (apache2handler)", respectively.

The bug can also be triggered with other messages that use magic words, such as 'grouppage-user' which contains {{ns:project}} and 'listgrouprights-summary' that contains {{MediaWiki:... The bug does not occur with messages of plain text, such as listgroupuserrights. Moreover, the bug could not be reproduced on MediaWiki 1.10alpha (r19729).

added dep on 14562 so they could find each other.

This was fixed a while back.

  • This bug has been marked as a duplicate of bug 28532 ***