Last modified: 2005-06-25 00:17:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1740 - A more advanced control over read access.
A more advanced control over read access.
Status: RESOLVED DUPLICATE of bug 1924
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-03-23 22:11 UTC by Marco Aurelio Valtas Cunha
Modified: 2005-06-25 00:17 UTC (History)
0 users

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


Description Marco Aurelio Valtas Cunha 2005-03-23 22:11:12 UTC
I've just installed the 1.4rc1 to manage some developer documentation but the
Wiki was elected to manage all documents on my site. The first trouble I've got
was the read access rights. 
 The Whitelist(Read|Edit|Account) works fine but how can I isolate part of the
Wiki from anonymous readers? What I need was an option like WhitelistRead but
doing the exactly the reverse thing, this way I could protect some restricted
information without worry with the growth of the Wiki. 
  Hacking the code I've came with some rough solution, here is it:

  First you will have another option in LocalSettings.php called
$wgProtectedPages witch is an
  So my LocalSettings.php looks like:

  # Disabling anonymous edits.
  $wgWhitelistEdit = true;
  # Specify who may create new accounts: 0 means no, 1 means yes
  $wgWhitelistAccount = array ( 'user' => 0, 'sysop' => 1, 'developer' => 0 );

  $wgWhitelistRead  = array('Main Page'); 
  $wgProtectedPages = array (
        'Systems.*LDAP$' #you can use RegExp here.


   For this work you should define $wgWhitelistRead, so putting the 'Main Page'
is a good idea since you probably won't block this page.

   Now, for the $wgProtectedPages you can define in each element an (Perl)
Regular Expression (I will use preg_match() to check the title) or the name of
the page you want to restrict.
   And now the hack itself, in Title.php (witch asks for the isAllowed('read')
in User.php), in function userCanRead() /Sorry but I have to paste some code here/:


                 } else {
                        global $wgWhitelistRead, $wgProtectedPages; # our new option
                        /** If anon users can create an account,
                            they need to reach the login page first! */
                        if( $wgUser->isAllowed( 'createaccount' )
                            && $this->getNamespace() == NS_SPECIAL
                            && $this->getText() == 'Userlogin' ) {
                                return true;

                        $name = $this->getPrefixedText();

                        # the new code, witch tries with preg_match() find
                        # if this page is protected so anon can't read this.
                        if (is_array($wgProtectedPages) ) {
                                foreach($wgProtectedPages as $pageName) {
                                        if( preg_match("/$pageName/",$name) ) {
                                                return false;
                                return true;

                        /** some pages are explicitly allowed */
                        if( in_array( $name, $wgWhitelistRead ) ) {
                                return true;

 With this kind of check I can protect a complete subtree, generate a
auto-protected for new pages using some keyword in the title, or protect just
one single page. As you can see $wgProtectedPages has precedence above

  Hope I didn't broke something, any thought?
Comment 1 MaPhi Werner 2005-04-19 14:08:26 UTC
Please check whether enhancement 1924
( fulfills your needs... 
Comment 2 Brion Vibber 2005-06-25 00:17:51 UTC

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

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