Last modified: 2010-05-15 15:56:46 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 T8251, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 6251 - $wgAvailableRights array causing some Special page not showing up in Special:Specialpages
$wgAvailableRights array causing some Special page not showing up in Special:...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.6.x
PC Windows XP
: Normal trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-09 15:06 UTC by Eris Discordia
Modified: 2010-05-15 15:56 UTC (History)
1 user (show)

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


Attachments

Description Eris Discordia 2006-06-09 15:06:08 UTC
I was toying with a local installation of MediaWiki 1.6.7 trying to manage access rights 
for anonymous users. In order to restrict access to all Special: pages (except Special:
Userlogin) I did as was told in:

http://meta.wikimedia.org/wiki/Preventing_Access#Preventing_access_to_some_SpecialPages

This worked. I set the $restriction parameter for all unrestricted pages (those without 
'rollback', 'unwatchedpages', etc) to a custom 'useronly' and granted 'sysop' the 
permission. Anonymous users could not access the pages anymore.

Later I noticed that Special:Specialpages has shrunken considerably and found out that 
all special pages whose access restriction was something but the usual pre-defined values 
would not show up in Special:Specialpages.

Tracing the problem I found in "includes/SpecialSpecialpages.php" the following code:

	foreach($wgAvailableRights as $right) {
		/** only show pages a user can access */
		if( $wgUser->isAllowed($right) ) {
			/** some rights might not have any special page associated */
			if(isset($pages[$right])) {
				$rpages = array_merge( $rpages, $pages[$right] );
			}
		}

in function wfSpecialSpecialpages(). Checking on $wgAvailableRights in "includes/Defines.
php" I figured out that this (static) array obviously did not contain my custom 
'useronly' or any other custom permissions. Since $right is enumerated against the 
array's contents any restriced page with permissions other than those in the array would 
not show in Special:Specialpages.

The function description/comment did include a line saying:

@todo Is this necessary?

So I guess this is going to be fixed but I am reporting it anyway to improve its chances 
of getting fixed.

Thanks.

WAMP Config (unnecessary I believe, but anyway):
Windows XP Professional (no SP)
Apache HTTP Server v2.0.58
MySQL 5.0.22 Community Edition
PHP 5.1.4
Comment 1 Tim Starling 2006-06-10 02:21:53 UTC
Maybe $wgAvailableRights should be moved to DefaultSettings.php. The best
solution for the reporter is almost certainly to add the custom user rights to
the array.
Comment 2 Eris Discordia 2006-06-10 20:37:18 UTC
That's right and I did that.

I think, however, that this should be fixed by dynamically listing all user rights 
(after all, they ought to be stored somewhere) and inserting them into 
$wgAvailableRights. I would do that myself if I know how to, but I do not so I would 
rather wait for a nice person's patch.

That would be a neater solution and newbies/newcomers (like me) will not have to 
mess with code or add extra things anywhere outside their own LocalSettings.php. 
Actually I had to change some lines of code (and I should not be doing that because 
I hardly have any idea of the entirety of the project) to make MediaWiki more 
suitable for a personal website (a rather big one, of course).
Comment 3 Siebrand Mazeland 2008-08-16 19:09:01 UTC
This issue was resolved by refactoring Special:Specialpages in r35670. All restricted pages are now shown.

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


Navigation
Links