Extension talk:WhiteList/Archive

Link to Unresolved issues

This page contains only resolved issues. To see unresolved issues, see the main talk page.

Modify/All/None

Please document the effects of checking and not checking the box in the Modify/All/None column. Svanslyck 23:02, 9 February 2008 (UTC)

Thanks for the suggestion. I added a much more detailed usage description on the main page. Hopefully this will clarify the usage. --Gri6507 03:28, 10 February 2008 (UTC)

Possible to use wildcard statements for namespace access?

I like the control and thoroughness of this extension, but am afraid that once my wiki has more than a few hundred pages, it will become difficult to manage permissions. Would it be possible to add wildcard statements in the whitelist over-ride, like ...

$wgWhitelistOverride['always']['read'] = array(
     "Project:*",       # grants everybody permission to see all pages in the Project namespace

Another feature would be to allow a working group to generate new content without a "manager" being present to grant each member of the workgroup access to each new page (effectively having to create new pages for the workgroup and then manage access to individual pages). A solution might be something like pseudo namespaces with wildcards. A workgroup leader could request that users x, y, and z could have permissions to new pseudo namespace "Foo". Then a manager could grant those users permissions using the whitelist access editor with "Foo:*"

This method would rely on new pages intended to be in a group of pages actually including the prefix. CWinDC 16:18, 23 February 2008 (UTC)

Thank you for the feedback. We are actually already working on the wildcard whitelist access. The next release version will have this support in it. I expect the next release to be sometime within a week. --Gri6507 17:56, 23 February 2008 (UTC)

Well, it's about a week late, but today, we released the new version of the extension which can handle wildcard entries. --Gri6507 19:12, 10 March 2008 (UTC)

How secure is this?

How well does this extension fare under http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions ? Are there ways to work around the whitelist?

You are correct to be concerned. That is why the top of the extension page has a rather lengthy disclaimer with a link to the same page you are referring to here :-). To see how well this extension fairs compared to other controlled access extensions, you can take a look at this listing (note, not everything that is listed in red is actually a bad thing).

The only additional comment I can make is that the developers (I am one of them) have taken every precaution to make this as bullet proof as possible. Based on our own testing, we have not found a way to bypass this extension yet. However, if you start poking into it, you may still find some holes which we will be glad to fix. The only other thing I can say, for whatever it's worth, is that this extension has been deemed secure enough for our internal company use. --Gri6507 00:03, 28 February 2008 (UTC)

I've added a Security Issues section which details security issues you might encounter. Note that you will need to make some changes to your MediaWiki config to make this extension effective, as described on that page. --Msul01 14:20, 28 February 2008 (UTC)

Blank page after activation of extension in LocalSettings.php

I followed the instructions like described, but I only got a blank page... After debugging I could find out, that you must give attention to exact file name.

• require_once( "$IP/extensions/WhiteList/SpecialWhiteListEdit.php" ); <- wrong, because of UPPER 'L' in WhiteList
• require_once( "$IP/extensions/WhiteList/SpecialWhitelistEdit.php" ); <- correct, with LOWER 'l' in Whitelist

So the files downloaded from WhiteList SVN can be found in extension directory! :)
--Topf 15:35, 17 May 2008 (UTC)

You are absolutely correct. Thank you for finding this. I'm surprised no one else has pointed this typo out so far :-) --Gri6507 18:44, 17 May 2008 (UTC)

Errors on WhiteList Special Page

In the file SpecialWhitelistEdit_body.php are some bugs...

• i.e. in lines 504, 505 and further (use search and replace)
  • found[ns] must be found['ns'], same with parameter 'title'

Actually the

found[ns]

syntax is perfecty legal. In PHP, the keys to arrays can be either integers or strings. By putting quotes around ns, you are forcing the key to be a string. Without the quotes, PHP interprets ns as a constant with some internally defined value. Depending on how strict you have your PHP error_reporting() set, you may or may not get a warning saying that the constant ns is undefined and is internally defined the value of 'ns' . --Gri6507 18:58, 17 May 2008 (UTC)

I reinstalled original file SpecialWhitelistEdit_body.php and when I call Special:WhiteList I get 75 notices (by PHP) (11x at Special:WhiteListEdit):

Notice: Use of undefined constant title - assumed 'title' in <...>/w/extensions/WhiteList/SpecialWhitelistEdit_body.php on line 504

Notice: Use of undefined constant ns - assumed 'ns' in <...>/w/extensions/WhiteList/SpecialWhitelistEdit_body.php on line 505

Following lines are affected: 504, 505, 512, 513, 540, 541. Nevertheless the rest of the page will be displayed. btw: I use MW 1.10.1 --Topf 23:17, 17 May 2008 (UTC)

I just checked my error_reporting() - and you were right... I forgot to reset it. So there are no notices in "normal" mode. Maybe you should remove this part "Errors on WhiteList Special Page" to do not confuse some users. ;) --Topf 00:07, 18 May 2008 (UTC)

I fixed this in v0.9.0 so that there should no longer be any warnings. --Gri6507 19:46, 20 May 2008 (UTC)

• give attention in line 535: don't modify this $sql string

--Topf 16:04, 17 May 2008 (UTC)

I'm not sure what you mean by this. Can you please clarify what you think is the problem? --Gri6507 18:58, 17 May 2008 (UTC)

I meant not to change [ns] to ['ns'] in this line, because it would end in an error. ;) --Topf 23:17, 17 May 2008 (UTC)

Blank user name in DropDownList of WhitelistEdit

Problem

If I want to change a user's whitelist, there appears an emtpy DropDownList entry (on page WhitelistEdit).

Reason

The user didn't enter a real name in its user settings.

Solution

• The user should enter a real name. ;)
• maybe better: The extension should choose user name instead of real name. What happens, if two users have the same real name??

--Topf 23:27, 17 May 2008 (UTC)

As of v0.9.0, I have updated the code to default to the Username if the UserRealName is not entered. Since the array is indexed by user IDs, it is possible to have two entries with the same realname. Unfortunately, there isn't much that can be done about that shy of forcing people to enter a unique real name. The only viable alternative is to display usernames which is not preferred in a workplace environment where everybody is known by their names and not their usernames. --Gri6507 19:49, 20 May 2008 (UTC)

=====

Installed v0.9.0 and I have the same problem. Username and UserRealName are correctly entered but I still have an empty DropDownList entry ?!
And for the display, why not showing both of them (Username and UserRealName) ???
--MoBO 12:30, 07 July 2008 (GMT+1)

Did you check your SQL user table? Look for an empty entry in the user_real_name field of the wiki_user table. --Msul01 14:54, 23 July 2008 (UTC)

I've just installed this extension (SVN revision 39298) on mediawiki 1.11.1. The dropdown select is not empty, it correctly shows the usernames. But the in-page text (e.g. when reviewing the changes about to be done) it is shown as 's instead of username's. So, this issue is only half-fixed. --CrazyTerabyte 17:53, 13 August 2008 (UTC)

Further resolution

This should be addressed in v0.11.2. --Gri6507 02:00, 11 November 2008 (UTC)

Class 'SpecialPage' not found

When I try to add the require_once line to my LocalSettings.php, I get the following error when loading a page on the Wiki:

Fatal error: Class 'SpecialPage' not found in /path/to/my/wiki/extensions/WhiteList/SpecialWhitelistEdit_body.php on line 47

Is there an extension or something else that I am missing that provides the definition of SpecialPage? I recently upgraded from 1.10 to 1.12, and otherwise this is a pretty much bog-standard MediaWiki installation. The only other extension we use is ParserFunctions.

I really hope I can get this to work; this is exactly the extension I am looking for. Thanks for your time. Withak 13:24, 17 June 2008 (UTC)

Can you please try adding

require_once("$IP/includes/SpecialPage.php");

in your LocalSettings.php right before the call to instantiate the WhiteList extension? --Gri6507 20:54, 17 June 2008 (UTC)

That appears to have worked — or at least I'm able to access the Wiki again. Thanks for the quick response! Withak 13:34, 18 June 2008 (UTC)

Well, I got a bit farther. I was able to add a test user to the "restricted" usergroup, add myself to the "manager" usergroup, and access Special:WhitelistEdit. However, this page doesn't appear to be rendering properly. The title of the page is "&lt;whitelistedit&gt;" and the table is filled with tags like <whitelistfor>, <whitelisttabletype>, <whitelisttabletype>, etc.

I did notice that in the instructions you call for edits to be made to MediaWiki:Common.css, saying that if my copy of this page doesn't have a section on "Dynamic Navigation Bars", to copy Wikipedia's version of the same page. Wikipedia's Common.js has a section on Dynamic Navigation Bars, but its Common.css does not. Withak 13:59, 18 June 2008 (UTC)

Never mind! Maybe I should have read this talk page a little more closely. :-) The fix for this problem is above: Extension talk:WhiteList#Error with Phrases in MediaWiki 1.12. Withak 16:53, 19 June 2008 (UTC)

invalid argument supplied foreach() in D:\wamp\www\mediawiki193\includes\MessageCache.php on line 636

my mediawiki is 1.11

Solution

This can be fixed by replacing all instances of $allMessages with $messages in all files of the extension. --195.13.40.237 17:14, 31 July 2008 (UTC)

Resolution

This has been permanently resolved in v 0.11.2. --Gri6507 02:01, 11 November 2008 (UTC)

Use of undef

Should you change line 118 in WhitelistAuth.php to look like line 48.

• $override = WHITELIST_NOACTION; {Line 48}
• $override = undef; {Line 118}

Chris Wolcott 13:04, 30 June 2008 (UTC)

Right now, the logic below line 118 guarantees that the undef will be changed before the function returns. I'll clean this logic up to set WHITELIST_NOACTION at line 118, then eliminate the 'else' clauses below. No reason to set the variable twice if we don't have to. Thanks for pointing this out. --Msul01 14:50, 23 July 2008 (UTC)

If PHP debug messages are activated like described in How to debug, the debugger advises me to use quotation marks in line 118 of WhitelistAuth.php

$override = "undef";  {Line 118}

--KMax 01:09, 3 September 2008 (UTC)

Resolution

This has been permanently resolved in v 0.11.2. --Gri6507 02:01, 11 November 2008 (UTC)

Internal error in MW 1.13

Internal error
 
Messages file for extensions WhiteList is not defined

Backtrace:

#0 /wiki/extensions/WhiteList/SpecialWhitelistEdit_body.php(647): wfLoadExtensionMessages('WhiteList')
#1 /wiki/includes/SpecialPage.php(365): WhiteList->WhiteList()
#2 /wiki/includes/SpecialPage.php(402): SpecialPage::getPage('WhiteList')
#3 /wiki/includes/specials/SpecialSpecialpages.php(18): SpecialPage::getUsablePages()
#4 /wiki/includes/SpecialPage.php(748): wfSpecialSpecialpages(NULL, Object(UnlistedSpecialPage))
#5 /wiki/includes/SpecialPage.php(534): SpecialPage->execute('wfSpecialSpecia...', NULL, Object(UnlistedSpecialPage))
#6 /wiki/includes/Wiki.php(224): SpecialPage::executePath(NULL)
#7 /wiki/includes/Wiki.php(55): MediaWiki->initializeSpecialCases(Object(Title))
#8 /wiki/index.php(93): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(WebRequest))
#9 {main}

-- ZoTyA 11:00, 28 August 2008 (UTC)

I'm in the middle of migrating our wiki to 1.13 and ran into the same thing. I got it to work with a few tweaks that haven't been posted to SVN yet (because I haven't had a chance to fully test them). I'll post the list of changes here later today. Sorry for the inconvenience. --Msul01 11:23, 28 August 2008 (UTC)

Here are the two changes I had to make to SpecialWhitelistEdit.php:

99c99
< $wgExtensionMessagesFiles['Whitelist']     = $dir . 'SpecialWhitelistEdit.i18n.php';
---
> $wgExtensionMessagesFiles['WhiteList']     = $dir . 'SpecialWhitelistEdit.i18n.php';
103c103
< $wgSpecialPages['WhiteList']               = 'WhiteList';
---
> $wgSpecialPages['Whitelist']               = 'Whitelist';

This fixes it for me. Make sure you also make the fix to the $allMessages variable if necessary (see #Error_with_Phrases_in_MediaWiki_1.12 --Msul01 14:31, 28 August 2008 (UTC)

Resolution

This has been permanently resolved in v 0.11.2. --Gri6507 02:03, 11 November 2008 (UTC)

Error accessing Special:Whitelist

After accessing Special:Whitelist (my pages) with a user in restricted group in MW 1.13

Error in fetchObject(): Table 'wiki.user_page_views' doesn't exist (localhost)

Backtrace:

#0 /wiki/extensions/WhiteList/SpecialWhitelistEdit_body.php(705): Database->fetchObject(Object(ResultWrapper))
#1 /wiki/includes/SpecialPage.php(534): WhiteList->execute(NULL)
#2 /wiki/includes/Wiki.php(224): SpecialPage::executePath(Object(Title))
#3 /wiki/includes/Wiki.php(55): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#4 /wiki/index.php(93): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#5 {main}

--JMK 19:43, 16 September 2008 (UTC)

Did you by chance try to modify the field names in the database table defined in Extension:WhiteList#Create the MySQL table? Your error is for accessing a field called user_page_views, and there isn't such a field in the table that is created for this extension.

Doing some further searching it looks like the Extension:UserSnoop and the Extension:UserPageViewTracker both create a custom table with that name. Do you by chance have either of those extensions installed? Does the error still happen if you disable ALL other extensions except for the WhiteList extension? --Gri6507 20:46, 16 September 2008 (UTC)

Extension:UserSnoop was not properly installed. After disabling the extension the error disappeared. Now the specialpage works as expected. Thank you. --JMK

Whitelist denies access to all pages that contain parentheses in the page title

Hi - after some pretty exhaustive debugging I have come to the conclusion that whitelist will not grant access, under any circumstances, to pages that have parentheses () in their title. Has anyone else found this to be true? Any ideas for a workaround that doesn't involve me renaming the 100+ pages in question that I am working with? Thanks. 72.0.222.219 19:52, 30 October 2008 (UTC)

I'm going to take a look at this next. --Gri6507 17:57, 31 October 2008 (UTC)

I have found the problem and the next version of the extension will include this, along with a number of other bug fixes. That version will come out as soon as testing is completed. If an earlier solution is needed, please contact me directly. --Gri6507 22:52, 6 November 2008 (UTC)

Resolution

This has been permanently resolved in v 0.11.2. --Gri6507 02:03, 11 November 2008 (UTC)

Error

I'm getting an error:

Fatal error: Class 'SpecialUserStats' not found in C:\wamp\www\sicherheitselektronik\extensions\WhiteList\SpecialWhitelistEdit_body.php on line 428

I suppose this is because I didn't install GNUplot or Extension:UsageStatistics, however I don't want the calendar functionality enabled. How do I comment this out or disable it? --Liface 13:36, 7 April 2008 (UTC)

You are correct. This is because you did not install the UsageStatistics extension. Right now, there is no easy way to remove this dependency shy of changing the extension code. However, I will make this configurable in the next version of the extension. Please stay tuned for updates. --Gri6507 13:58, 7 April 2008 (UTC)

Ah, okay, I misunderstood the installation instructions. I installed UsageStatistics, but I still have this bug (which was present before): http://img150.imageshack.us/img150/1786/screenshotzl4.png. It seems to be just taking the text in the database instead of converting it into any meaningful format. Any ideas? --Liface 11:14, 8 April 2008 (UTC)

I wouldn't quite call it a bug; just a lack of functionality :-). The problem is that it doesn't appear that there are i18n translations available for your locale. What locale is your account set for? Take a look at SpecialWhitelistEdit.i18n.php to see which translations are already available. My guess is that this extension is still missing the translations for your locale. You are very welcome to create the translation yourself. It is very easy - simply follow the format you see in the file. When you have it finished, please post it here and I will submit it to SVN. --Gri6507 12:35, 8 April 2008 (UTC)

The requirement for the UsageStatistics extension has been made optional as of v0.8.6 --Gri6507 13:01, 14 April 2008 (UTC)

syntax error in SpecialWhitelistEdit_body.php

After activating the WhiteList extension in LocalSettings.php the following message occurs:

Parse error: syntax error, unexpected '}' in /srv/www/htdocs/wiki/extensions/WhiteList/SpecialWhitelistEdit_body.php on line 755

But my SpecialWhitelistEdit_body.php does only contain 749 lines!

cat SpecialWhitelistEdit_body.php | wc -l
749

I'm not closed enough to the php to fix it on my own. Sorry.
--, KMax 09:47, 2 September 2008 (UTC)

What version of the extension was this regarding? Currently, in v 0.10.0, the file SpecialWhitelistEdit_body.php contains 747 lines. --Gri6507 20:51, 16 September 2008 (UTC)

Error with Phrases in MediaWiki 1.12

I had a problem that non of the phrases showed up. I just got the <...> crap.

I tracked it down to this.

Error

In file includes/MessageCache.php, Line 712 and 713 use the variable '$messages'. This '$messages' varbible is pulled from the i18n file. The i18n file for this hack though uses the varible '$allMessages' and not '$messages' as it seems MediaWiki wants you to.

Fix

Open file SpecialWhitelistEdit.i18n.php and SpecialWhitelistEdit_body.php and replace all instances of '$allMessages' with '$messages'.

Good catch, thanks for providing the fix. There's a note in 1.9 saying that $allMessages is no longer needed, and someone probably pulled it out since then. We'll make this fix with the next update. --Msul01 14:43, 23 July 2008 (UTC)

Resolution

This has been permanently addressed in v0.11.2. --Gri6507 13:10, 12 November 2008 (UTC)