Last modified: 2012-04-15 04:22:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16959, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14959 - UNIQ... exposed to anonymous users when hook "InternalParseBeforeLinks" uses specific messages
UNIQ... exposed to anonymous users when hook "InternalParseBeforeLinks" uses ...
Status: RESOLVED DUPLICATE of bug 28532
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.13.x
All All
: Low major (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser, testme
Depends on: 14562 17329
Blocks: UNIQ
  Show dependency treegraph
 
Reported: 2008-07-28 13:58 UTC by Markus Krötzsch
Modified: 2012-04-15 04:22 UTC (History)
2 users (show)

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


Attachments

Description Markus Krötzsch 2008-07-28 13:58:43 UTC
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 http://sandbox.semantic-mediawiki.org/wiki/UNIQ_bug (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.
Comment 1 Markus Krötzsch 2008-07-28 14:27:54 UTC
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).
Comment 2 Mark A. Hershberger 2010-12-02 20:32:57 UTC
added dep on 14562 so they could find each other.
Comment 3 Bawolff (Brian Wolff) 2012-04-15 04:22:08 UTC
This was fixed a while back.

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

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


Navigation
Links