Last modified: 2011-03-13 18:05:05 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 1924 - Restricted read access for subset of wiki
Restricted read access for subset of wiki
Status: CLOSED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest enhancement with 18 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Hidden...
:
: 784 1740 2227 8360 (view as bug list)
Depends on:
Blocks: 2422 3075
  Show dependency treegraph
 
Reported: 2005-04-19 14:02 UTC by MaPhi Werner
Modified: 2011-03-13 18:05 UTC (History)
3 users (show)

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


Attachments
Restricted namespace access for 1.4.1 (22.99 KB, patch)
2005-04-19 14:04 UTC, MaPhi Werner
Details
Restricted namespace access for HEAD / 1.5 (21.64 KB, patch)
2005-04-19 14:06 UTC, MaPhi Werner
Details
Readme for the patches (1.55 KB, text/plain)
2005-04-19 14:06 UTC, MaPhi Werner
Details
Restricted namespace access for 1.4.3 (27.53 KB, patch)
2005-05-03 19:32 UTC, MaPhi Werner
Details
Restricted namespace access for 1.5alpha1 (25.30 KB, patch)
2005-05-03 19:46 UTC, MaPhi Werner
Details
Updated for v1.4.5 (24.19 KB, patch)
2005-06-26 07:43 UTC, Markus Meissner
Details
Updated for v1.5beta4 (18.76 KB, patch)
2005-09-08 00:46 UTC, Nick Kossifidis
Details
Update + addons for 1.5rc4 (23.74 KB, patch)
2005-09-20 09:55 UTC, Nick Kossifidis
Details
Diff to restrict the output of groups on the Special:Listusers page for non-sysops (403 bytes, text/plain)
2005-10-28 11:20 UTC, Jason Riddell
Details
Update + addons for 1.5.1 (24.09 KB, patch)
2005-11-02 00:00 UTC, Nick Kossifidis
Details
Update + addons for 1.5.3 (27.52 KB, patch)
2005-12-08 03:48 UTC, Nick Kossifidis
Details
Display Access Denied message when no namespace permission (2.54 KB, patch)
2005-12-08 13:25 UTC, Jody Foo
Details
Update + addons for 1.5.5 (31.92 KB, patch)
2006-01-18 19:04 UTC, Nick Kossifidis
Details
Addons for 1.5.7 (based on 1.5.5 addons 1316, munged for 1.5.7) (40.23 KB, patch)
2006-03-16 08:09 UTC, Pawel O
Details
Addons for 1.5.7 (based on 1.5.5 addons 1316, munged for 1.5.7) (32.43 KB, patch)
2006-03-16 08:54 UTC, Pawel O
Details
Restricted namespace access on SVN/Head 2006-04-06 + Addons 1452 (29.23 KB, patch)
2006-04-07 20:24 UTC, Alfons Zitterbacke
Details
Addons for 1.6.3 with Display Access Denied message when no namespace permission patch (based SVN/Head 2006-04-06 + Addons 1452) (40.42 KB, patch)
2006-04-22 22:05 UTC, Andrei Cojocaru
Details
Restricted namespace access for 1.6.5 (39.54 KB, patch)
2006-05-13 07:37 UTC, Cyril Dangerville
Details
Restricted namespace access for 1.6.7 (based on 1714) (32.32 KB, patch)
2006-06-10 23:49 UTC, Andreas Hubel
Details
Adds "your namespaces" to sidebar for 1.6.3. (1.46 KB, patch)
2006-07-03 22:12 UTC, Dan Davis
Details
Adds "your namespaces" to sidebar for 1.6.3 (1.60 KB, patch)
2006-07-03 22:22 UTC, Dan Davis
Details
Updated for 1.7.1 (includes "your namespaces" in the sidebar) (39.22 KB, patch)
2006-07-13 18:17 UTC, Dan Davis
Details
Updated for 1.7.1 (includes "your namespaces" in the sidebar) (39.88 KB, patch)
2006-07-13 18:30 UTC, Dan Davis
Details
Updated for 2082 for 1.8.2 (42.38 KB, patch)
2006-11-09 22:21 UTC, Joseph Southwell
Details
Updated for 1.8.2 (two bugs fixed) (38.88 KB, patch)
2006-12-08 09:33 UTC, Noel
Details

Description MaPhi Werner 2005-04-19 14:02:24 UTC
It should be possible to restrict read access for a subset of the wiki pages to
specific users. This might not be necessary for Wikipedia, but is essential for
company wikis. 

This enhancement has been brought up before on sourceforge. 

References to related requests:
http://bugzilla.wikipedia.org/show_bug.cgi?id=1740
http://sourceforge.net/tracker/index.php?func=detail&aid=979095&group_id=34373&atid=411195
http://sourceforge.net/tracker/index.php?func=detail&aid=1014562&group_id=34373&atid=411195
Comment 1 MaPhi Werner 2005-04-19 14:04:59 UTC
Created attachment 431 [details]
Restricted namespace access for 1.4.1

This patch makes it possible to restrict read access to namespaces. See readme
for details.
Comment 2 MaPhi Werner 2005-04-19 14:06:18 UTC
Created attachment 432 [details]
Restricted namespace access for HEAD / 1.5

Patch for HEAD. See readme for details
Comment 3 MaPhi Werner 2005-04-19 14:06:43 UTC
Created attachment 433 [details]
Readme for the patches
Comment 4 MaPhi Werner 2005-04-19 14:12:43 UTC
Possible solution:
- Read access is limited on a per-namespace basis
- Only user defined namespaces (> 100) can be restricted

See also http://meta.wikimedia.org/wiki/Hidden_pages 
Comment 5 MaPhi Werner 2005-05-03 19:32:51 UTC
Created attachment 490 [details]
Restricted namespace access for 1.4.3

Update for 1.4.3.

Fixes:
- Moves of restricted pages are now blocked for non-authorized users
- It is possible to disable logging to RecentChanges, so protecting or deleting
restricted pages is not visible to the world. See DefaultSettings.php
- The RSS feed is no longer cached when restricted pages are in effect, so each
user sees the changes according to his restrictions
Comment 6 MaPhi Werner 2005-05-03 19:46:17 UTC
Created attachment 491 [details]
Restricted namespace access for 1.5alpha1

Update for 1.5alpha1

Fixes:
- Moves of restricted pages are now blocked for non-authorized users
- It is possible to disable logging to RecentChanges, so protecting or deleting

restricted pages is not visible to the world. See DefaultSettings.php
- The RSS feed is no longer cached when restricted pages are in effect, so each

user sees the changes according to his restrictions

Note: 
My production wiki runs under 1.4.3 at the moment, so the 1.5 version of the
patch does not see much testing at the moment.
Comment 7 Paul 2005-06-24 15:23:08 UTC
This is something I really wish could get put in 1.5(or support put in so it
could be easily implemented with an extension). This is a very important feature
for semi-private wikis
Comment 8 Brion Vibber 2005-06-25 00:17:51 UTC
*** Bug 1740 has been marked as a duplicate of this bug. ***
Comment 9 Brion Vibber 2005-06-25 00:18:28 UTC
*** Bug 2227 has been marked as a duplicate of this bug. ***
Comment 10 Brion Vibber 2005-06-25 00:21:51 UTC
*** Bug 784 has been marked as a duplicate of this bug. ***
Comment 11 Markus Meissner 2005-06-26 07:43:40 UTC
Created attachment 649 [details]
Updated for v1.4.5

Applied the above patch (id=490) to the 1.4.5 sources. Apply with 
cd mediawiki-1.4.5
patch -p1 < rra-1.4.5.patch

Note that if you are using php < 4.2 (e.g. Debain Woody) you can use
http://pear.php.net/package/PHP_Compat to have the function var_export which is
required by the patch.
Comment 12 Zigger 2005-07-10 06:43:03 UTC
See also bug 2073 (Default page restrictions for each namespace), which also has
patches.
Comment 13 Frédéric Bonnaud 2005-08-23 10:01:13 UTC
the patch for 1.5alpha1 doesn't work any more with 1.5beta4 
Comment 14 Nick Kossifidis 2005-09-08 00:46:43 UTC
Created attachment 863 [details]
Updated for v1.5beta4

It worked for me, should work for rc4 too. (Sorry for the poor diff stuff, it's
my first patch and i had some probs with cvs so i created it localy, should
apply corectly using "patch -p0 < patch" ).
Comment 15 Nick Kossifidis 2005-09-08 00:51:19 UTC
Comment on attachment 863 [details]
Updated for v1.5beta4

Changes:

-less use of foreach

-less sql query tweaks
Comment 16 Sider 2005-09-13 09:33:05 UTC
Your patch 'attachment 863 [details]' doesn't seem to work, i tried on v1.5beta3 and 
v1.5beta4 with cygwin patching utility, thats whats it reported:

$ patch -p0 < patch.diff
(Stripping trailing CRs from patch.)
patching file includes/CategoryPage.php
(Stripping trailing CRs from patch.)
patching file includes/DefaultSettings.php
Hunk #1 succeeded at 1328 (offset 8 lines).
(Stripping trailing CRs from patch.)
patching file includes/LogPage.php
(Stripping trailing CRs from patch.)
patching file includes/Parser.php
Hunk #1 succeeded at 2061 (offset 8 lines).
Hunk #2 succeeded at 2225 (offset 8 lines).
(Stripping trailing CRs from patch.)
patching file includes/SearchEngine.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialAllpages.php
Hunk #3 FAILED at 44.
Hunk #4 succeeded at 184 (offset -9 lines).
1 out of 4 hunks FAILED -- saving rejects to file includes/SpecialAllpages.php.r
ej
(Stripping trailing CRs from patch.)
patching file includes/SpecialContributions.php
Hunk #5 FAILED at 265.
1 out of 5 hunks FAILED -- saving rejects to file includes/SpecialContributions.
php.rej
(Stripping trailing CRs from patch.)
patching file includes/SpecialExport.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialLog.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialPreferences.php
Hunk #2 succeeded at 89 (offset 1 line).
Hunk #3 succeeded at 352 (offset 14 lines).
Hunk #4 succeeded at 369 (offset 14 lines).
(Stripping trailing CRs from patch.)
patching file includes/SpecialRecentchanges.php
Hunk #3 FAILED at 133.
Hunk #4 succeeded at 248 (offset 1 line).
Hunk #5 succeeded at 277 (offset 1 line).
1 out of 5 hunks FAILED -- saving rejects to file includes/SpecialRecentchanges.
php.rej
(Stripping trailing CRs from patch.)
patching file includes/SpecialRecentchangeslinked.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialWantedpages.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialWhatlinkshere.php
(Stripping trailing CRs from patch.)
patching file includes/Title.php
Hunk #1 succeeded at 998 (offset 1 line).
Hunk #2 succeeded at 1012 (offset 1 line).
(Stripping trailing CRs from patch.)
patching file includes/User.php
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 1018 with fuzz 1.
Comment 17 Sider 2005-09-13 09:34:48 UTC
Sorry, i forgot to say that this was the report for v1.5beta4.
Comment 18 Sider 2005-09-13 11:30:57 UTC
The report for v1.5beta3:

$ patch -p0 < patch3.diff
missing header for unified diff at line 3 of patch
(Stripping trailing CRs from patch.)
patching file includes/CategoryPage.php
(Stripping trailing CRs from patch.)
patching file includes/DefaultSettings.php
Hunk #1 succeeded at 1293 (offset -27 lines).
(Stripping trailing CRs from patch.)
patching file includes/LogPage.php
Hunk #1 succeeded at 64 (offset -5 lines).
(Stripping trailing CRs from patch.)
patching file includes/Parser.php
Hunk #1 succeeded at 2050 (offset -3 lines).
Hunk #2 succeeded at 2214 (offset -3 lines).
(Stripping trailing CRs from patch.)
patching file includes/SearchEngine.php
Hunk #1 succeeded at 137 (offset -13 lines).
(Stripping trailing CRs from patch.)
patching file includes/SpecialAllpages.php
Hunk #1 succeeded at 9 with fuzz 2.
Hunk #2 succeeded at 20 with fuzz 1 (offset 1 line).
Hunk #3 FAILED at 45.
Hunk #4 FAILED at 194.
2 out of 4 hunks FAILED -- saving rejects to file includes
ej
(Stripping trailing CRs from patch.)
patching file includes/SpecialContributions.php
Hunk #1 FAILED at 16.
Hunk #2 FAILED at 74.
Hunk #3 succeeded at 101 (offset -21 lines).
Hunk #4 FAILED at 126.
Hunk #5 FAILED at 244.
4 out of 5 hunks FAILED -- saving rejects to file includes
php.rej
(Stripping trailing CRs from patch.)
patching file includes/SpecialExport.php
Hunk #2 succeeded at 307 (offset -8 lines).
(Stripping trailing CRs from patch.)
patching file includes/SpecialLog.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialPreferences.php
Hunk #1 FAILED at 37.
Hunk #3 succeeded at 329 (offset -9 lines).
Hunk #4 succeeded at 346 (offset -9 lines).
1 out of 4 hunks FAILED -- saving rejects to file includes
p.rej
(Stripping trailing CRs from patch.)
patching file includes/SpecialRecentchanges.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialRecentchangeslinked.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialWantedpages.php
(Stripping trailing CRs from patch.)
patching file includes/SpecialWhatlinkshere.php
(Stripping trailing CRs from patch.)
patching file includes/Title.php
Hunk #1 succeeded at 977 (offset -20 lines).
Hunk #2 succeeded at 991 (offset -20 lines).
(Stripping trailing CRs from patch.)
patching file includes/User.php
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 998 with fuzz 1 (offset -20 lines).
Comment 19 Nick Kossifidis 2005-09-13 13:49:30 UTC
Weird, i Just tried that on a pure 1.5beta4 ,

mathematix:/home/mick# tar xvzf mediawiki-1.5beta4.tar.gz
...
mathematix:/home/mick/mediawiki-1.5beta4# patch -p0
</var/www/wiki/restrict_access.patch
patching file includes/CategoryPage.php
patching file includes/DefaultSettings.php
patching file includes/LogPage.php
patching file includes/Parser.php
patching file includes/SearchEngine.php
patching file includes/SpecialAllpages.php
patching file includes/SpecialContributions.php
patching file includes/SpecialExport.php
patching file includes/SpecialLog.php
patching file includes/SpecialPreferences.php
patching file includes/SpecialRecentchanges.php
patching file includes/SpecialRecentchangeslinked.php
patching file includes/SpecialWantedpages.php
patching file includes/SpecialWhatlinkshere.php
patching file includes/Title.php
patching file includes/User.php
mathematix:/home/mick/mediawiki-1.5beta4#

Are you sure you haven't applied any other patch on the source ?

If the patching stuff doesn't work you can do it by hand (see the patch file and
you'll get the picture), also the errors you get are for some special pages, the
main stuff (user.php, title.php, parser.php) seems to be o.k. (that means that
the user want be able to read or edit any page in the namespace) try patching
these special pages by hand (so that the user want be able to see the references
to the namespace on those special pages).

If you have trouble with that, mail me the php files that have probs
(SpecialAllpages, SpecialContributions, SpecialRecentpages etc) and I'll try to
patch them for u...

Mick
Comment 20 Sider 2005-09-14 10:17:04 UTC
Erm..sorry i just discovered that the report in #16 is based on MW 1.5 rc4. 

It would be very nice for me if i had a patch for MW 1.5 beta3 because my wikis
run this version and any changing of this would increase my lack of time. ;-) 

So I will mail you the files to patch now.
Comment 21 Nick Kossifidis 2005-09-14 21:33:30 UTC
You got Mail ;-) Hope it works (couldn't test it)...

I 'll make a patch for rc4 soon, stay tuned...

Mick
Comment 22 Nick Kossifidis 2005-09-20 09:55:14 UTC
Created attachment 902 [details]
Update + addons for 1.5rc4

Changes...

* More examples in configuration

* No tweaking on the way logs are kept, just the way they show up. The feature
of disabling the logging in Recent chancges has been replaced by a better
(IMHO) way of hiding the desired logs in both Recent Changes and Special:Log.
Now an array of the log types to be hidden exist:

<i>Logs in Recent Changes are treated all the same, so normaly users will be
able
to see moves, protects and deletes of pages in restricted namespaces. Setting
this var to true will hide all logs in Recent Changes and only those for
restricted namespaces in Special:Log.

$wgHideLogs = false;

In case you want to customize what logs the user can see both in Recent Changes

and Special:Log, modify this array to include the log types you want to
hide.This is overriden by $wgHideLogs for Recent Changes and those logs for
restricted namespaces in Special:Log. This feature lets you hide also the
'block' and 'rights' log types that are namespace independed in Special:Log, or
show them in RC while hiding the rest.
</i>

* Cleaned a lot of useless stuff from the previous patch.

* In some cases of custom log hiding it might get slower e.g if you want to
hide them all, use the $wgHideLogs, don't fill up the array, the more stuff the
array has the slower it gets (but not too slow).


Addons...

* In case you have categories of pages located on a restricted namespace those
categories will appear empty and might be comfusing. So now there is a way to
hide category edits etc in RC.

* In case some user tries to create a link from some namespace to an other
restricted namespace, while the page gets parsed, instead of the link, a
warning message will appear ('restrlink') to let the user know. If the link is
in the same namespace as the edited page, no check will be done.

Tested and worked for me, for probs make a comment or mail me.

Hope u like it (and sorry for my poor english ;-) )
Nick
Comment 23 JDPorter 2005-09-25 20:06:23 UTC
Patch for 1.5rc4 installed & works flawlessly
Comment 24 JDPorter 2005-09-25 20:39:52 UTC
Suggestion: Patch replaceInternalLinks in parser.php to render restricted links
as plaintext for unpriviledged users.
Comment 25 Nick Kossifidis 2005-09-25 20:53:17 UTC
That can't be done because parser runs every time you save or edit the document
(it's better that way, imagine the load if every time a user requests a page
that page was re-parsed). So no per user check can be done in parser, the only
thing i could think off is the warning thingie. Thanx for the feedback !!! :-)
Comment 26 lɛʁi לערי ריינהארט 2005-10-05 17:14:05 UTC
pair of bugs

*read privilege* bug 1924: Restricted read access for subset of wiki
*edit privilege* bug 679: Editing mediawiki so only certain users can edit
certain pages
Comment 27 Paul 2005-10-10 16:25:51 UTC
Patch applied against the 1.5 release - successful and so far working perfectly.
Great job. Is there any chance this patch can be considered for inclusion into
MediaWiki?
Comment 28 Rob Church 2005-10-10 22:06:39 UTC
Highly unlikely that it would be implemented as anything other than an
extension. MediaWiki is a wiki engine, not a document management system; we tend
to take to the wiki philosophy that all users should be free to edit everything.
Comment 29 Nathan Koren 2005-10-11 15:58:53 UTC
This is a very much-needed patch; thank you for creating it!  However, it isn't
working for me.  I successfully patched it to 1.5.0, and have created an extra
namespace thusly:

$wgExtraNamespaces =
	array(100 => "Chronology",
	      101 => "Chronology_Talk",
	      102 => "AlumniDB",
	      103 => "AlumniDB_Talk"
	      );

Then I created a group like this, and made myself a member of it:

$wgGroupPermissions['DB_Manager']['read'] = true;
$wgGroupPermissions['DB_Manager']['edit'] = true;

And finally I restrict the namespace:

$wgRestrictedNamespaces = 
	array(102 => array ("DB_Manager"), 103 => array ("DB_Manager"));

However, whenever I go to the namespace, I get an error page with this message:

"Login Required

 You must login to view other pages.

 Return to Main Page."

What am I doing wrong?  I have tried restricting the namespace to "sysop" and
even "user", but always to the same effect.  If somebody could help me with
this, I'd be most appreciative.

By the way... I'm setting up this wiki to provide services for an alumni group
of about 7,000 people.  All of them will have access to the wiki.  However, we
are also developing a database of the alumni, with a lot of very sensitive
personal information in it.  The wiki is, naturally, the perfect medium for
collaboration between the smaller group of DB developers, however the
information they are working with should OBVIOUSLY not be publically available
for every mass-marketer and stalker-ex to collect.  Hence the acute need for
this kind of restricted namespace function.  If the "wiki philosophy" can't
accommodate this reality, then the wiki philosophy is flat-out WRONG.
Comment 30 JDPorter 2005-10-11 16:25:42 UTC
Nathan,
I've done something quite similar for my own school. Set up your permissions thusly:
 $wgGroupPermissions['DB_Manager']['AlumniDB']= true;
 $wgGroupPermissions['DB_Manager']['AlumniDB_talk']= true;
You see? User group, then restricted namespace.
Comment 31 Nathan Koren 2005-10-11 16:43:32 UTC
Hi JDPorter,
Thanks for the reply; alas, doing this has no effect.  Any other suggestions?
Comment 32 Nick Kossifidis 2005-10-11 19:27:27 UTC
Try this...

$wgExtraNamespaces =
array(100 => "Chronology",
101 => "Chronology_Talk",
102 => "AlumniDB",
103 => "AlumniDB_Talk"
);

You have created the extra namespaces and the group fine but remember that u
don't asign namespaces to user groups but to user rights (so more user groups
with the same right can have access to restricted namespaces).

$wgGroupPermissions['DB_Manager']['read'] = true;
$wgGroupPermissions['DB_Manager']['edit'] = true;

So u need to asign a new right to the user group, let's say "Manager"...

$wgGroupPermissions['Db_Manager']['Manager'] = true;

And finally restrict the namespace to the user groups with the "Manager" right
(note the way you enter values to the array, it's different from 1.4 patch
described in the "Hidden pages" wiki page  - plz someone with better English
skills edit it):

$wgRestrictedNamespaces = array(102 => 'Manager', 103 => 'Manager');

This should be fine :-)
Comment 33 Nathan Koren 2005-10-11 21:54:28 UTC
Hi Nick,

Thanks for the help.  Unfortunately, this approach isn't working either. :-( 
Does anybody have an example of a LocalSettings.php file that works under
Mediawiki 1.5.0 that I could duplicate, and then then modify for my own needs?

Thanks!
Comment 34 Paul 2005-10-11 23:10:05 UTC
Nathan,

This is the relevant section of LocalSettings.php from my wiki, with info
anonymized. Basic idea is to clear all permissions on everything, setup arrays
with the permissions you want for certain groups, and then apply the permissions
to all:

$wgExtraNamespaces = array(100 => "test1", 101 => "test1_Talk",
                           102 => "test2", 103 => "test2_Talk",
                           104 => "test3", 105 => "test3_Talk");

$wgRestrictedNamespaces = array(104 => "TT_NS1", 105 => "TT_NS2");


$vips = array("group1", "group2", "group3");
$vip_privs = array("block", "checkuser", "createaccount", "delete", "edit",
"editinterface", "import", "importupload", "move", "patrol",
                        "protect", "checkuser", "read", "renameuser", "upload",
"userrights", "TT_NS1", "TT_NS2");

$peons = array("low_group1", "low_group2", "low_group3");
$peon_privs = array("edit", "read", "upload");

$wgGroupPermissions = array(); // clear everyone's permissions to everything

foreach($peons as $peon)
        foreach($peon_privs as $peon_priv)
                $wgGroupPermissions[$peon][$peon_priv] = true;
foreach($vips as $vip)
        foreach($vip_privs as $vip_priv)
                $wgGroupPermissions[$vip][$vip_priv] = true;
Comment 35 Christian Preuner 2005-10-17 11:42:09 UTC
Can somebody post the patch for the 1.5 release?
If i apply the patch, i get this output:

patch < wikipatch -p0
patching file includes/CategoryPage.php
patching file includes/DefaultSettings.php
Hunk #1 succeeded at 1331 (offset 11 lines).
patching file includes/LogPage.php
patching file includes/Parser.php
Hunk #1 succeeded at 2062 (offset 9 lines).
Hunk #2 succeeded at 2226 (offset 9 lines).
patching file includes/SearchEngine.php
patching file includes/SpecialAllpages.php
Hunk #3 FAILED at 44.
Hunk #4 succeeded at 184 (offset -9 lines).
1 out of 4 hunks FAILED -- saving rejects to file includes/SpecialAllpages.php.rej
patching file includes/SpecialContributions.php
Hunk #5 FAILED at 265.
1 out of 5 hunks FAILED -- saving rejects to file
includes/SpecialContributions.php.rej
patching file includes/SpecialExport.php
patching file includes/SpecialLog.php
patching file includes/SpecialPreferences.php
Hunk #2 succeeded at 89 (offset 1 line).
Hunk #3 succeeded at 352 (offset 14 lines).
Hunk #4 succeeded at 369 (offset 14 lines).
patching file includes/SpecialRecentchanges.php
Hunk #3 FAILED at 133.
Hunk #4 succeeded at 248 (offset 1 line).
Hunk #5 succeeded at 277 (offset 1 line).
1 out of 5 hunks FAILED -- saving rejects to file
includes/SpecialRecentchanges.php.rej
patching file includes/SpecialRecentchangeslinked.php
patching file includes/SpecialWantedpages.php
patching file includes/SpecialWhatlinkshere.php
patching file includes/Title.php
Hunk #1 succeeded at 998 (offset 1 line).
Hunk #2 succeeded at 1012 (offset 1 line).
patching file includes/User.php
Comment 36 Matt Shepherd 2005-10-27 15:18:32 UTC
Nathan,

The problem you are having is probably due to you setting
$wgRestrictedNamespaces and (possibly or) $wgExtraNamespaces AFTER you've set
$wgPermissions.

i.e., try moving the $wgRestrictedNamespaces and $wgExtraNamespaces blocks to a
location in the file above $wgPermissions.

By doing this, I got it working on 1.5.1.

I don't know if this causes other problems, but it is most likely the cause of
the problem you're experiencing.

--Matt Shepherd
Comment 37 Matt Shepherd 2005-10-27 16:42:50 UTC
I take that back..  I'm not able to restrict the viewing of pages by group
simply using $wgExtraNamespaces, $wgRestrictedNamespaces, $wgPermissions.
Comment 38 Jason Riddell 2005-10-28 11:20:16 UTC
Created attachment 1030 [details]
Diff to restrict the output of groups on the Special:Listusers page for non-sysops 

This is a diff of the changes I have made to restrict the visibility of groups
to non-sysop users. The patch makes the drop down user group select and the
users current groups not be displayed for anyone who isn't a sysop. There is
probably a more elegant way of doing this but this method suited my needs,
uploading it as it maybe useful for others who need are using groups to
restrict namespaces and don't want them visible to all.

Thanks,
Jason.
Comment 39 Jason Riddell 2005-10-28 11:23:31 UTC
Oops, forgot to say the diff is against MediaWiki 1.5.1 and the restricted
namespace patch installed and is working just fine.

Jason.
Comment 40 Nick Kossifidis 2005-11-02 00:00:40 UTC
Created attachment 1037 [details]
Update + addons for 1.5.1

New Features added:

Now it's possible to restrict editing in public namespaces (those readable by
anyone) and allow editing only in restricted namespaces (only those locked to
the usergroup). Two new rights added for this, the 'sedit' right which allows
the user to edit in the restricted namespaces he has access to and the 'talk'
right which allows the user to edit talk pages.

So you can allow someone to edit only talk pages or only private pages or both
and don't give him the 'edit' right to edit public pages.

Have Fun :-)

Mick
Comment 41 Nick Kossifidis 2005-11-02 00:03:11 UTC
Note: Jason's patch should work fine with the new patch (couldn't test it).

Nick
Comment 42 Mark Bober 2005-11-02 18:31:35 UTC
Is there any method within this for opening up a namespace to public reads and
talks, but limiting edits to a group?

I'd expect the proper solution would be a wgLimitedNamespaces array alongside
wgRestrictedNamespaces, that grants 'read' and/or 'talk' access to a listed
namespace for '*', and edit to those with the named right?

The #40 comment seems to hold really close to what I'm looking for, Nick, it
almost just needs to be reversed (edit public and Restricted namespaces as
usual, read/talk in namespaces the user *doesn't* have access to, if defined).

I'm setting up a departmental Wiki here, and I'd like the user's options to be:

1) Public Wiki default namespace, editable by all users, readable by world
2) Public Wiki group namespaces, editable by user groups, readable/talkable by world
3) Private Wiki namespaces, as this patch provides.

#2 solves to problem of wanting to set up multiple, seperate Wikis for each group.

Thanks!

Mark
Comment 43 Nick Kossifidis 2005-11-03 00:03:29 UTC
I guess you are looking for the right combination of priviledges.

1)
$wgGroupPermissions['*']['read'] = true;
$wgGroupPermissions['*']['talk'] = true;
$wgGroupPermissions['user']['edit'] = true;

2)This can't be done because restricted namespaces (locked to groups) are hidden
from anyone who doesn't have access to them (no read access), they are not
public. However you can allow 'talk' to users (that means they won't be able to
read the namespace but they will be able to read and edit namespace_talk). I
sugest you keep a public namespace (main)in which finished pages from resticted
namespaces end up (e.g. you write a page in the restricted/hidden namespace and
then you protect it -no further editing possible- and move it to the public
namespace so anyone can read it and talk for it). This is a nice feature you are
asking, if I can find some time I'll see what i can do, maybe an 'sread' right
is what we want.

In my case in PA.SO.K. we want to have a public namespace in which we will place
all of our finished pages for reading/talking, and have a pivate/hidden
namespace for each group to work independently. Each group has a group admin
that moves the pages from the private namespace to the public when they are
ready. Group users have the 'sedit' right instead of the 'edit' and group admins
have the 'edit' right.
Comment 44 Vinh Vu 2005-11-03 22:31:04 UTC
Would this patch work if I use LDAP for authentication?
http://meta.wikimedia.org/wiki/LDAP_Authentication

If you have implemented it could you please share some of the troubles that you
might have gone through?

Thanks,
Vinh
Comment 45 christian 2005-11-04 09:27:17 UTC
Hello, I used to patch on mediawiki 1.5.2 and it seems to work ok apart from
this error I keep getting:

Warning:in_array() [function.in-array]: Wrong datatype for second argument in
mediawiki/includes/User.php on line 1046

There was also an error about wrong datatype where it assumed a constant, I
fixed that by adding quotes around 'edit' on line 1045 in User.php

Does anyone have any clue on how to solve the issues?

Thanks, 
Christian
Comment 46 christian 2005-11-04 09:51:13 UTC
I think I 'fixed' it already. I had to add the variables to the config file for
it to work :)
Comment 47 JiangXin 2005-11-05 06:44:37 UTC
(In reply to comment #45)
> I keep getting:Warning:in_array() [function.in-array]: 

add $wgRestrictedNamespaces = NULL to config file, warning also exisit there. 
Fixed like that:
+    if( is_array( $wgRestrictedNamespaces ))
+    {
         if( in_array($ns, $wgRestrictedNamespaces) && $this->canAccessNamespace($ns) ) {
                  if( ($action == edit) && (in_array('sedit', $this->mRights)) ) {
                           return true;
                  }
         }
+    }
Comment 48 Torsten Schmidt 2005-11-17 10:17:43 UTC
>> Created an attachment (id=1037) [edit]
>> Update + addons for 1.5.1

i've installed this patch on 1.5.0 and it works, thanks for this patch Nick.

one question to the message being displayed, if an unauthorized user trys to
access a restricted ns:

i get the following text (translated from the german version):

----
Login required!
you have to [[Special:UserLogin]] to view other pages.
Back to [[Mainpage]]
----

this doesn't make so much sense.
how could i change this message to something like: 
you don't have the Right to view this page. / you're not allowed to view this page.

Thanks in advance.
Torsten
Comment 49 Rob Church 2005-11-20 15:15:08 UTC
Special:Allmessages
Comment 50 Nick Kossifidis 2005-11-21 21:36:35 UTC
I found a bug in the implementation of 'sedit' right, it seems that it doesn't work.

To fix that go to includes/User.php line 1047 and change

if( in_array($ns,$wgRestrictedNamespaces) && $this->canAccessNamespace($ns) ) {

to 

if( $this->canAccessNamespace($ns) ) {

Also do what JiangXin sugests.

Sorry ppl, i didn't test that feature well :-(

A new patch is almost ready, I' ll release it soon..

Nick
Comment 51 Nick Kossifidis 2005-11-21 21:44:55 UTC
also change 

if( ($action == edit) && (in_array('sedit', $this->mRights)) ) {

to

if( !$title->isProtected() && ($action == edit) && (in_array('sedit',
$this->mRights)) ) {

so that protected pages inside restricted namespaces are not editable

Nick
Comment 52 Donn Morrison 2005-11-27 22:25:31 UTC
Is it possible with this patch to have a namespace read-only for certain users?
I'd still like to have the namespace restricted for editing, but don't want the
restricted pages hidden from everyone.
Comment 53 christian 2005-11-28 12:57:17 UTC
I use this patch on 1.5.0 and it works likes a charm. 
Now I would like to use a custom authentication scheme using my own extension of
the AuthPlugin interface. However the wiki doesn't seem to respond to any
changes I make to the custom authentication class.
Is it still possible to extend this interface after using this plugin?
Comment 54 C. Filipe Medeiros 2005-12-03 00:49:32 UTC
I'm having a problem with this patch on 1.5.2. This is the setup I have:

$wgExtraNamespaces = array(
  100 => 'Code',
  101 => 'Skinne',
  102 => 'SLF',
  103 => 'Content'
  );

$wgRestrictedNamespaces = array(
  100 => array('coder'),
  101 => array('projectskinne'),
  102 => array('projectslf'),
  103 => array('content')
);

// Permissions
// "Code" Namespace
$wgGroupPermissions['sysop']['Code'] = true;
$wgGroupPermissions['coder']['Code'] = true;

// "Skinne" Project Namespace
$wgGroupPermissions['sysop']['Skinne'] = true;
$wgGroupPermissions['projectskinne']['Skinne'] = true;

// "SLF" Project Namespace (SportLegsFan.com)
$wgGroupPermissions['sysop']['SLF'] = true;
$wgGroupPermissions['projectslf']['SLF'] = true;

// "Content" namespace
$wgGroupPermissions['sysop']['Content'] = true;
$wgGroupPermissions['content']['Content'] = true;


When I try to access [[Code:Main]] it asks me to login (when I am already logged
in).

When I try to Move a page to Code:Main, it returns an error on the same page
saying "Protected Page"
Comment 55 Nick Kossifidis 2005-12-03 08:57:02 UTC
Try this...

$wgExtraNamespaces = array(
100 => 'Code',
101 => 'Code_talk',
102 => 'Skinne',
103 => 'Skinne_talk',
104 => 'SLF',
105 => 'SLF_talk',
106 => 'Content'
107 => 'Content_talk'
);

$wgRestrictedNamespaces = array(
100 => 'coder',
102 => 'projectskinne',
104 => 'projectslf',
106 => 'content'
);

// Permissions
// "Code" Namespace
$wgGroupPermissions['sysop']['coder'] = true;
$wgGroupPermissions['coder']['coder'] = true;

// "Skinne" Project Namespace
$wgGroupPermissions['sysop']['projectskinne'] = true;
$wgGroupPermissions['projectskinne']['projectskinne'] = true;

// "SLF" Project Namespace (SportLegsFan.com)
$wgGroupPermissions['sysop']['projectslf'] = true;
$wgGroupPermissions['projectslf']['projectslf'] = true;

// "Content" namespace
$wgGroupPermissions['sysop']['Content'] = true;
$wgGroupPermissions['content']['content'] = true;

Read the DefaultSettings.php and you 'll find examples there, also read the 
previous messages here.

a) You asign a namespace to a right in $wgRestrictedNamespaces 
($wgRestrictedNamespaces = array(100=>'coolguy')).
b) You asign the right to a usergroup ($wgGroupPermissions['User_group']
['coolguy'] = true;
c) Always create the talk namespaces because the way you have made your 
configuration Skinne is the talk namespace of Code and Content is the talk 
namespace of SLF.

Nick
Comment 56 Nick Kossifidis 2005-12-03 08:58:55 UTC
The new patch for 1.5.2 will probably be ready on Thuesday, it will have a new feature for read 
only namespaces (that are not hidden in the logs) and a few bugfixes...

Nick
Comment 57 Jody Foo 2005-12-04 19:48:35 UTC
Sounds great Nick! I just found your patch and it exactly what I need. Thanks
for your effort!
Comment 58 Donn Morrison 2005-12-08 01:16:45 UTC
Hey Nick, any progress on the latest 1.5.2 patch?

Donn
Comment 59 Nick Kossifidis 2005-12-08 03:48:51 UTC
Created attachment 1153 [details]
Update + addons for 1.5.3

Patch for 1.5.2 also works for 1.5.3.

2 New features...

a) Read-Only Namespaces, now you may put all the namespaces you want to be read
only to an array. Users with the 'roread' right can read them, users with the
'rowrite' right can edit them. These are not locked to usergroups yet (not
specific right per namespace), that means if someone has the 'rowrite' right,
can edit every read only namespace, same goes for 'roread'. Read only
namespaces are not hidden (no log hiding).

b) For those users that have access to restricted namespaces, a list to the
main page of each restricted namespace they have access to is being displayed
after they log in. Each link is formed by the name of the namespace and the
'mainpage' message. Also on top of the list a new 'RNSlist' message is being
displayed, to edit the message go to MediaWiKi:RNSlist.

For more info check out includes/DefaultSettings.php (documentation is there)

Hope it works fine :-)
Nick

P.S. By the way the title of this bug entry is way out of date, I' ll create a
new bug entry sometime.

P.S.2 I also created a patch for changing the logo and the sidebar per
namespace, check it out (4042).
Comment 60 Nick Kossifidis 2005-12-08 03:55:14 UTC
I forgot to mention i also added a feature to hide User talk stuff from
Special:Recentchanges

Nick
Comment 61 C. Filipe Medeiros 2005-12-08 06:22:22 UTC
I'm still trying to figure out all the code (I've been able to make a couple
edits for my own purposes here-and-there) but I was wondering what I would have
to change to return an "Access Denied" page rather than just sending them to the
"Login" page whenever they try to access a restricted resource.

Or is there something wrong with my installation?
Comment 62 Nick Kossifidis 2005-12-08 07:17:45 UTC
Check out includes/OutputPage.php and the function returnToMain() whitch is
called in such situations.

Nick
Comment 63 Jody Foo 2005-12-08 13:04:18 UTC
I too wanted to have this so I added a few lines to the function loginToUse() in
includes/OutputPage.php

I ended up with this:

function loginToUse() {
	global $wgUser, $wgTitle, $wgContLang;

        $usersNamespaces = $wgUser->getAllowedRNSes();
        $usersNamespacesArray = explode("\n", $usersNamespaces);
        $currentNamespace = Namespace::getCanonicalName($wgTitle->getNamespace());
        
        # If the user tries to access an extra namespace but does not have
        # the correct permissions, display an Access Denied message.
        # You need to define MediaWiki:noaccesstitle and MediaWiki:noaccesstext
        if($wgTitle->getNamespace() >= 100) {
            if(!in_array($currentNamespace, $usersNamespacesArray)) {
                $this->setPageTitle( wfMsg( 'noaccesstitle' ) );
                $this->setHTMLTitle( wfMsg( 'errorpagetitle' ) );
                $this->setRobotpolicy( 'noindex,nofollow' );
                $this->setArticleFlag( false );
                $this->mBodytext = '';
                $this->addWikiText( wfMsg( 'noaccesstext' ) );
            }
        }
        
        else {        
            $this->setPageTitle( wfMsg( 'loginreqtitle' ) );
            $this->setHTMLTitle( wfMsg( 'errorpagetitle' ) );
            $this->setRobotpolicy( 'noindex,nofollow' );
            $this->setArticleFlag( false );
            $this->mBodytext = '';
            $this->addWikiText( wfMsg( 'loginreqtext' ) );
        }

		# We put a comment in the .html file so a Sysop can diagnose the page the
		# user can't see.
		$this->addHTML( "\n<!--" .
						$wgContLang->getNsText( $wgTitle->getNamespace() ) .
						':' .
						$wgTitle->getDBkey() . '-->' );

        # Do not return to the main page automatically if the user tried to access
        # an extra namespace. Only return if the user tried, but failed to access
        # a system namespace.
        if($wgTitle->getNamespace() < 100) {
            $this->returnToMain();	# Flip back to the main page after 10 seconds.
        }
}
Comment 64 Jody Foo 2005-12-08 13:25:17 UTC
Created attachment 1155 [details]
Display Access Denied message when no namespace permission

This patch works after applying the 1.5.3 patch for restricting namespace
access.
Comment 65 Christos Gavos 2005-12-14 14:15:34 UTC
This is fabulous! I did manage to create Private Namespaces and all. But is
there a way to make the “main” namespace private and then create a public
namespaces?

For example, 

Everything posted under the “main” namespace is private

Everything posted under the “Public:” name space is world readable

Everything posted under the “FlexPublic:” name space is readable and writable

Regards,
cgavos
Comment 66 Stephen Kennedy 2005-12-18 06:57:10 UTC
Will this be making its way into the official code?
Comment 67 Brion Vibber 2005-12-18 07:28:02 UTC
No. MediaWiki doesn't target this type of environment, and our
policy is to be open about the fact that we are not built for
that, since security problems in an unmaintained, half-done
approach are likely to crop up constantly.

If you actually need fancy read restrictions to keep some of
your own people from reading each others' writing, MediaWiki is
not the right software for you.

I hadn't realized this bug was actually still open, I'm resolving
it as WONTFIX.
Comment 68 Matt Shepherd 2005-12-21 16:56:18 UTC
While I understand what Brion Vibber has said here and elsewhere many times, I
still feel that MediaWiki suits my needs very well aside from the lack of good
Access Control.  I'm willing to do what I need to do to ensure that after this
patch is implemented on my wiki, that the wiki remains secure.

I feel that part of the beauty of open source software is that even if the
community that developed it is not interested in a certain aspect or feature,
that feature can be developed, implemented, and maintained by someone 'outside'
of the community so that those who are interested can use it.

I work in a Software Development department at a large ISP.  If is possible that
if there is a need we may end up developing further access control ourselves as
we have evaluated many other collaborative documentation repository solutions
and like what MediaWiki has to offer.

MaPhi, will you be continuing to post updates at another location?  Since Brion
has made it clear on many occassions that there are no foreseeable plans to
implement something like this, perhaps we should find a forum where this patch
and it's updates can be posted, downloaded, and discussed freely?
Comment 69 Edward Z. Yang 2005-12-25 19:43:55 UTC
You're likely going to have to fork MediaWiki, albeit make it a closely
synchronized fork. MediaWiki, after all, is used for WikiMedia's projects, and
the MediaWiki team has done a great job patching MediaWiki so that it's
deployable on other systems. However, you can only do so much without
implementing ugly hacks or introducing performance problems.
Comment 70 Nick Kossifidis 2005-12-25 20:45:59 UTC
Brion Vibber is right, MediaWiKi's design is to be open for editing etc and
focuses on other important things. This is a hack for MediaWiKi and it will
remain a hack as long as someone is maintaining it (MaPhi Werner, me, someone
else perhaps). It shouldn't be in the oficial MediaWiKi because MediaWiKi should
be redisigned from scratch and adapt a new user policy etc (that means e.g. new
database scema, different architecture, different session hanlding etc) for this
to work corectly. This hack does not guarantee security etc. I personaly liked
MediaWiKi's interface and features and wanted to mod it for my needs so i used
and maintained this patch. If you want to have a wiki with user managemend in
mind (lot's of permissions to add or remove, more options upon user rights, per
article access control etc), try something else.
Comment 71 Nick Kossifidis 2006-01-18 19:04:53 UTC
Created attachment 1316 [details]
Update + addons for 1.5.5

Lots of bugfixes, tested mostly with 1.5.3 but works for 1.5.5 too...

Some add-ons:

* Users in Special:Listusers can only see the users in their usergroup (to undo
this overwrite includes/Speciallistusers.php from the main distribution).

* A new variable {{ns}} added, that gets the name of the current namespace
(this helps with management), especialy with #4042 can be very helpfull in
sidebars.
Comment 72 Nick Kossifidis 2006-01-18 19:05:46 UTC
forgot to mention the above patch can be applied with -p1 instead of -p0...
Comment 73 Nick Kossifidis 2006-01-19 06:48:13 UTC
I got a report about another bug, users that are not logged in can edit their
user-page (IP), to fix this, go to User.php
in function isallowed, find 


// If we are in user's page, allow him to do everything...
                if ( $action == 'edit' && ($ns == NS_USER_TALK || $ns == NS_USER)...


                if ( $action == 'protect' && ($ns == NS_USER_TALK || $ns ==
NS_USER)...

and change it to...

// If we are in user's page, allow him to do everything...
                if ( $this->isLoggedIn() && $action == 'edit' && ($ns ==
NS_USER_TALK || $ns == NS_USER)...


                if ( $this->isLoggedIn() && $action == 'protect' && ($ns ==
NS_USER_TALK || $ns == NS_USER)...
Comment 74 lɛʁi לערי ריינהארט 2006-02-01 15:17:00 UTC
(In reply to comment #71)
> * A new variable {{ns}} added, that gets the name of the current namespace
> (this helps with management), especialy with #4042 can be very helpfull in
> sidebars.

This is the request from
Bug 2162: enhancement request for a new variable GENERICNAMESPACE
Comment 75 Ben Greear 2006-02-08 08:29:42 UTC
I'm using mediawiki 1.5.6 with the 1.5.5 patch, and having trouble.  I'm new to
wiki, so I could be missing something trivial.

I have added a new group using mysql commands:
mysql> select * from user_groups;
+---------+------------+
| ug_user | ug_group   |
+---------+------------+
|       1 | bureaucrat |
|       1 | candela    |
|       1 | sysop      |
+---------+------------+
3 rows in set (0.00 sec)

My local-settings looks like this:
## Access restriction settings.

$wgExtraNamespaces = array(
101 => 'Private'
);

$wgRestrictedNamespaces =
        array(101 => 'candela'
             );

$wgGroupPermissions['sysop']['candela'] = true;
$wgGroupPermissions['candela']['candela'] = true;

$wgLinkWarn = true;

----

I'm using this wiki-markup in my main page to try to create a private
link, available only to user 1:

* [[Private:Private]] Restricted pages, not for public consumption.

I'm logged in as user 1, but when I display the main page, I
see this:

 <restrlink> Restricted pages, not for public consumption.

Any ideas what I'm doing wrong?

Thanks,
Ben Greear <greearb@candelatech.com>
Comment 76 Octavi Estapé 2006-02-09 11:00:59 UTC
(In reply to comment #73)
Hi Nick! Very good work! I thougth it was impossible to do this with MediaWiki
and I was thinking in changing to a different wiki engine! Thanks!

I found two things that maybe you want to change in the patch:

(1) I get a warning:

Warning: substr_count(): Empty substring. in ...\includes\SpecialListusers.php
on line 177

to solve it you can change (near line 177 in SpecialListusers)
     if( substr_count($rUsergroups, $tUserGroups[$i]) >0 ){
for
     if( strlen($tUserGroups[$i])>0 && substr_count($rUsergroups, $tUserGroups[$i])

(2) If you apply the patch "Diff to restrict the output of groups on the
Special:Listusers page for non-sysops" you still can see the groups because in
Recentchanges you can see things like this (even if you are not in the group
"testgroup")

(Bureaucrat log); 09:42 . . Admin (Discusión) (Changed group membership for
Usuario:TestUser from to testgroup) 

I don't care a lot, but maybe is a problem for someone else.

Thanks again!

Octavi
Comment 77 Octavi Estapé 2006-02-09 13:39:01 UTC
(In reply to comment #75)

Hi Ben! I discovered this patch yesterday so maybe I'm wrong.

You can write
$wgLinkWarn = false;

and the link will show the same way as the others. I didn't like this (I want a
warning AND a link) and changed Parser.php near line 1337 the lines:

	$s .=wfMsg( 'restrlink' ). $trail;
	continue;

commented something:
	$s .=wfMsg( 'restrlink' );//. $trail;
	//continue;

Then you have to create the page MediaWiki:Restrlink and write something you
want to appear before the restricted links. I wanted to appear an image of a
lock so I tried something like [[Image:log.gif]] but doesn't work. If you write
the url like:
http://www.example.com/lock.gif
without any wiki format, it works!

You should create the pages MediaWiki:RNSlist (appears in the login) and
MediaWiki:templatenotincluded (appears if you try to do a template with
restricted pages).
Comment 78 Xavier Belanche 2006-02-24 09:33:38 UTC
Hi Octavi,
I have the same problem about <restrlink>. I have this conf in the localsettings.php

$wgGroupPermissions['*'         ]['createaccount']      = false;
$wgGroupPermissions['*'         ]['read']               = true;
$wgGroupPermissions['*'         ]['edit']               = false;
$wgGroupPermissions['sysop'     ]['edit']               = true;
$wgGroupPermissions['sysop'     ]['read']               = true;
$wgGroupPermissions['sysop'     ]['createaccount']      = true;
$wgGroupPermissions['sysop'     ]['renameuser']      = true;
$wgGroupPermissions['sysop'     ]['userrights']      = true;
$wgGroupPermissions['ninja'         ]['read']               = true;
$wgGroupPermissions['ninja'         ]['edit']               = true;


#NameSpaces propios de la estructura del curso XTEC
$wgExtraNamespaces = array (
        100 => "CURS",
        101 => "MODUL",
        102 => "PRACTICA",
        103 => "EXERCICI",
        104 => "GUIA",
        105 => "AJUDA"
);
$wgNamespacesWithSubpages = array (
        100 => 1, 101=> 1, 102=> 1, 103=> 1, 104=> 1, 105=> 1);
$wgNamespacesToBeSearchDefault = array (100=> 1 , 101=> 1, 102=> 1, 103=> 1,
104=> 1, 105=> 1);



## Relación entre los grupos de usuarios y los NameSpaces
$wgGroupPermissions['sysop'     ]['cusito']      = true;
$wgGroupPermissions['sysop'     ]['modulito']      = true;
$wgGroupPermissions['*'         ]['cursito']      = false;
$wgGroupPermissions['*'         ]['modulito']      = false;
$wgGroupPermissions['ninja'     ]['cursito']      = true;
$wgGroupPermissions['ninja'     ]['modulito']      = false;



## Afegim als keys dels namespaces els noms dels grups de restricció :=)
$wgRestrictedNamespaces = array(100 => "cursito", 101 => "modulito");

$wgLinkWarn = false;

At this point, when I visit one MODUL or CURS page, it appears something like this:
http://phobos.xtec.net/curslinkat/formacio/index.php/Linkat
Well, I would to know how its the better way to work or solution!

Thanks, 
Javier

PD: Octavi, felicitats pel teu projecte de robòtica. Apa, ajuda'm!!!!!
Comment 79 John Beranek 2006-02-24 14:24:02 UTC
After much tearing out of hair, I did eventually get access restriction to a
namespace, but one thing remains.

What is 'RSNlist' message meant to say? I can't quite understand what it's there
for based on the patch/comments.
Comment 80 John Beranek 2006-02-24 14:42:41 UTC
[Apologies, I meant RNSlist in comment #79]

In fact, can we have examples of all the messages:

- restrlink
- templatenotincluded
- RNSlist

any others?
Comment 81 Xavier Belanche 2006-02-28 07:49:43 UTC
Hey,
Just rules :) I have a problem of permissions! Thanks for your feedbacks :)_

Javier
Comment 82 violendom 2006-03-01 10:06:41 UTC
Hi, I had some particular needs :

* I wanted to view the restricted link if it's allowed and in a different
namespace page.
* The page must not be cached if a restricted link is present, because the page
is different for differnt user
* The page can be cached if the restricted link is in the same namespace of the page
* I need a template to display an open lock near the allowed restricted link
(restrallowedlink)

so I've changed Parser.php to satisfy my needs : 

#If the link points to a restricted namespace outside the
#parent namespace warn the user.
global $wgRestrictedNamespaces, $wgLinkWarn, $wgUser;
if( $wgLinkWarn && is_array( $wgRestrictedNamespaces )) {
  if( array_key_exists( $ns, $wgRestrictedNamespaces ) ) {			
    if ($this->mTitle->getNamespace() != $ns) {
      #If the restricted link is in a page with a differnt namespace
      #do not cache.
      $this->disableCache();
    }	
    if ( $wgUser->isAllowed($wgRestrictedNamespaces[$ns]) ) {
      $s .=wfMsg( 'restrallowedlink' );
    } else {
      $s .=wfMsg( 'restrlink' ). $trail;
      continue;
    }
  }
}

It would be nice with some conf variables to configure the link display behaviour
Comment 83 Martin Müller 2006-03-02 08:57:43 UTC
hi,
i have running mediawiki 1.5.6. Is it necessary to patch 1.5.6  or is it
necessary to include an extension to enable private and puplic wiki pages?

Which example on this bugzilla-side is running? Or can anybody post me an
running LocalSettings.php.  

which convention is correct?
$wgGroupPermissions['Groupname']['restrictedNamespaceName']         = true; 
or
$wgGroupPermissions['Groupname']['Right']         = true;

thanks in advanced for "any" answer
Comment 84 Martin Müller 2006-03-02 09:01:26 UTC
hi,
i have running mediawiki 1.5.6. Is it necessary to patch 1.5.6  or is it
necessary to include an extension to enable private and puplic wiki pages?

Which example on this bugzilla-side is running? Or can anybody post me an
running LocalSettings.php.  

which convention is correct?
$wgGroupPermissions['Groupname']['restrictedNamespaceName']         = true; 
or
$wgGroupPermissions['Groupname']['Right']         = true;

thanks in advanced for "any" answer
Comment 85 Pawel O 2006-03-16 08:09:52 UTC
Created attachment 1450 [details]
Addons for 1.5.7 (based on 1.5.5 addons 1316, munged for 1.5.7)

No updates here. Just munged patch from
[http://bugzilla.wikimedia.org/attachment.cgi?id=1316&action=edit|addons for
1.5.5] to jive with plain 1.5.7 release.
Comment 86 Pawel O 2006-03-16 08:54:48 UTC
Created attachment 1451 [details]
Addons for 1.5.7 (based on 1.5.5 addons 1316, munged for 1.5.7)

Sorry, I've been smoking crack and original patch did not, err, patch cleanly.
This one does.
Comment 87 Vinnie 2006-03-18 00:34:49 UTC
Is there a simple piece of code that will allow a general user to edit the talk
page and nothing else?
Comment 88 Hiram 2006-03-22 20:00:12 UTC
Pawel O: Your patch produces the following error when a user not in any
namespace group askes for List Users:<BR>
Warning:  substr_count() [<a
href='function.substr-count'>function.substr-count</a>]: Empty substring. in
includes/SpecialListusers.php <BR>
It is from the following section of code:<BR>
<PRE>
+                       $incl = false;
+                       $rUsergroups = implode(',',$groups);
+                       $tUserGroups = $wgUser->getGroups();
+                       for( $i = 0; count($tUserGroups) >= $i; $i++) {
+                               if( substr_count($rUsergroups, $tUserGroups[$i])
>0 ){
+                                       $incl = true;
+                                       break;
+                               }
+                       }
</PRE>
Comment 89 Jean-Gabriel 2006-04-05 21:15:14 UTC
Hello,

(first : thanks Nick Kossifidis for this patch, it helps a lot 
setting up corporate wikis).

We'd like to also protect uploaded files, i.e. be able to upload 
files that could then be retrieved only by a group of users. 

Does the patch allow to do this ?  For this purpose, it would be nice 
if we could use the same restrictions that are set up by the way of 
this patch, for "normal" wiki pages !

Thanks in advance ...
Comment 90 Alfons Zitterbacke 2006-04-07 20:24:49 UTC
Created attachment 1508 [details]
Restricted namespace access on SVN/Head 2006-04-06 + Addons 1452

I updated 1452 to work with recent SVN Code (2006-04-06).
Comment 91 Ivan Vighetto 2006-04-14 09:42:46 UTC
Applying the patch, doesn't work "preferences". I added $wgUser as global in
function namespacesCheckboxes() in SpecialPreferences.php and works ok.
Comment 92 Ivan Vighetto 2006-04-14 09:43:10 UTC
After applying the patch, doesn't work "preferences". I added $wgUser as global
in function namespacesCheckboxes() in SpecialPreferences.php and works ok.
Comment 93 Silvia Pfeiffer 2006-04-14 10:35:23 UTC
I run mediawiki 1.5.7 and have applied
mediawiki-1.5.7-restriction-patch-beta-0.62.tar.gz . The section that I have
restriced is all pages that contain "Restricted/" in them.

It works, but when I use "search", the restricted pages also come up as search
results.
Try http://www.annodex.org/ and search for "restricted".

I checked the source code, but couldn't find out why. Can anyone help?
Comment 94 Andrei Cojocaru 2006-04-22 22:05:31 UTC
Created attachment 1598 [details]
Addons for 1.6.3  with Display Access Denied message when no namespace permission patch (based SVN/Head 2006-04-06 + Addons 1452)

Hi,

I recently set up a MediaWiki installation and was looking for exactly what
this patch provided! However, it seemed there was no version for 1.6.3, however
I decided to try SVN/Head 2006-04-06 + Addons 1452 with Display Access Denied
message when no namespace permission (had to do some light hacking for the
latter because of some changed code in loginToUse() and there was also a slight
bug in the first in wfSpeciAllpages() since it didn't have global $wgUser).
Anyways, thanks to the writers for the mentioned patches, they did the real
work.

Hopefully, people will keep posting patches to enable this functionality, hope
this helps others.

P.S. I forgot to mention above, that I didn't do any extensive testing, but
after using the wiki for a couple of days it seems to work fine with no side
effects except that little bug in wfSpecialAllpages(). Also it seems the
restricted patches aren't included in Search either unless you have permission
(let me know if I'm wrong).
Comment 95 Andrei Cojocaru 2006-04-22 23:32:19 UTC
(In reply to comment #93)
> I run mediawiki 1.5.7 and have applied
> mediawiki-1.5.7-restriction-patch-beta-0.62.tar.gz . The section that I have
> restriced is all pages that contain "Restricted/" in them.

That file refers to the patch referenced from
http://conseil-recherche-innovation.net/index.php/1974/04 which is different
from the namespace restriction patch on this page. It seems to support
restricting namespaces implicitly by matching the namespace followed by colon
part not explictly like this patch. Also, it only has one group of "authorized"
 users, while this patch supports as many restriction groups as you want by
implementing restriction as a user right rather than a user group.
Comment 96 Roland Rosenfeld 2006-04-23 18:23:07 UTC
(In reply to comment #94)
> Addons for 1.6.3  with Display Access Denied message when no namespace
> permission patch (based SVN/Head 2006-04-06 + Addons 1452)

As far as I can see, this breaks the "what links here" link.  The following
patch solves this:

+++ includes/SpecialWhatlinkshere.php   Sun Apr 23 20:19:38 2006
@@ -73,7 +73,7 @@
         * @access private
         */
        function showIndirectLinks( $level, $target, $limit, $from = 0, $dir =
'next' ) {
-               global $wgOut;
+               global $wgOut, $wgUser;
                $fname = 'WhatLinksHerePage::showIndirectLinks';
 
                $dbr =& wfGetDB( DB_READ );
Comment 97 Roland Rosenfeld 2006-04-23 18:45:17 UTC
And another problem with 1.6.3:

--- includes/SpecialPreferences.php.org Sun Apr 23 20:27:10 2006
+++ includes/SpecialPreferences.php     Sun Apr 23 20:27:47 2006
@@ -370,7 +370,7 @@
         * @access private
         */
        function namespacesCheckboxes() {
-               global $wgContLang;
+               global $wgContLang, $wgUser;
 
                # Determine namespace checkboxes
                $namespaces = $wgContLang->getNamespaces();
Comment 98 Didier Courtaud 2006-05-04 13:03:01 UTC
The attachment 1598 [details] does not seem to work with Mediawiki 1.6.5 :

patching file includes/CategoryPage.php
patching file includes/DefaultSettings.php
Hunk #1 succeeded at 1567 (offset 13 lines).
patching file includes/Export.php
patching file includes/OutputPage.php
Hunk #1 FAILED at 748.
1 out of 1 hunk FAILED -- saving rejects to file includes/OutputPage.php.rej
patching file includes/Parser.php
patching file includes/QueryPage.php
patching file includes/SearchEngine.php
patching file includes/SpecialAllpages.php
patching file includes/SpecialContributions.php
patching file includes/SpecialListusers.php
patching file includes/SpecialLog.php
patching file includes/SpecialPreferences.php
patching file includes/SpecialRandompage.php
patching file includes/SpecialRecentchanges.php
patching file includes/SpecialRecentchangeslinked.php
patching file includes/SpecialUserlogin.php
Hunk #1 succeeded at 410 (offset -1 lines).
patching file includes/SpecialWantedpages.php
Hunk #1 succeeded at 71 (offset 3 lines).
patching file includes/SpecialWhatlinkshere.php
patching file includes/Title.php
patching file includes/User.php
Comment 99 Cyril Dangerville 2006-05-13 07:37:58 UTC
Created attachment 1714 [details]
Restricted namespace access for 1.6.5

Based on patch for 1.6.3. Resolved the conflict on includes/OutputPage.php
mentioned by Didier Courteau in last comment to make it compatible with 1.6.5.
Comment 100 Cyril Dangerville 2006-05-13 07:45:11 UTC
Comment on attachment 1714 [details]
Restricted namespace access for 1.6.5

Based on attachment #1598 [details].
Do not forget to define MediaWiki:RNSlist, MediaWiki:noaccesstitle and
MediaWiki:noaccesstext.
Comment 101 Stephan Braun 2006-05-22 18:22:48 UTC
I used this patch for 1.5.7 and everything seems to work fine except for the RSS
feed for recent changes. The feed includes the changes of restriced (hidden)
pages which should not be so. Is there anything to change this behaviour?
Comment 102 jbm 2006-06-01 20:10:55 UTC
The patch for 1.6.5 seems to be imcopatible with 1.6.6

Hunk #1 succeeded at 120 with fuzz 2 (offset 5 lines).
patching file includes/DefaultSettings.php
Hunk #1 FAILED at 1554.
1 out of 1 hunk FAILED -- saving rejects to file
includes/DefaultSettings.php.rejpatch
Comment 103 Andreas Hubel 2006-06-10 23:49:47 UTC
Created attachment 1933 [details]
Restricted namespace access for 1.6.7 (based on 1714)

just updated 1714 to MediaWiki 1.6.7
Comment 104 Octavi Estapé 2006-06-14 12:17:06 UTC
I think I found a possible security hole. If you include a restricted page in a
non restricted page you can see the contents, even if you don't have access to
the restricted namespace.

Try writing {{:RestrictedNS:NameOfThePage}} in a non restricted page
(RestrictedNS is the restricted namespace and NameOfThePage the name of the page).

To solve it, I added an "else" near line 2268 in includes/Parser.php

    # Articles from restricted namespaces can't be used in templates.
    # They would appear or disappear based on the rights of the user
    # that refreshes the cache...
    if( is_array( $wgRestrictedNamespaces ) ) {
        if( array_key_exists( $title->getNamespace(), $wgRestrictedNamespaces ) ) {
            $found = true;
            $text = $linestart . wfMsg( 'templatenotincluded' );
        }
    }
+    else
    if ( $title->getNamespace() == NS_SPECIAL &&
$this->mOptions->getAllowSpecialInclusion() ) {

Anyone can tell me if I'm right? Thanks

Octavi
Comment 105 Octavi Estapé 2006-06-14 12:52:04 UTC
Never mind my previous post, I introduced the security hole to my wiki some time
ago when I did some changes to the code. All the patches here are ok. Sorry!

Octavi
Comment 106 Octavi Estapé 2006-06-14 14:07:19 UTC
I've been looking at my changes and the patches and after all maybe my post #104
was right. My wiki has too many changes to know it for sure. Can somebody check
it? Thanks

Octavi
Comment 107 Andreas Hubel 2006-06-18 09:14:15 UTC
I certify this bug. In my wiki it also works. 
Someone must build a new patch.
Comment 108 Octavi Estapé 2006-06-20 09:23:19 UTC
In comment #104 there is a mistake and it will prevent to appear any template
(even the ones of non restricted namespaces). To solve it, we have to merge the
two "if" (and leave the "else" after):

# Articles from restricted namespaces can't be used in templates.
# They would appear or disappear based on the rights of the user
# that refreshes the cache...
if( is_array( $wgRestrictedNamespaces ) && array_key_exists(
$title->getNamespace(), $wgRestrictedNamespaces ) ) {
  $found = true;
  $text = $linestart . wfMsg( 'templatenotincluded' );
} 
else if ( $title->getNamespace() == NS_SPECIAL && ...
Comment 109 Marcus Schwarz 2006-06-23 00:40:51 UTC
(In reply to comment #103)
> Created an attachment (id=1933) [edit]
> Restricted namespace access for 1.6.7 (based on 1714)
> 
> just updated 1714 to MediaWiki 1.6.7


I have some troubles with this patch.
First I often receive a message like "<restrlink>", which I hadn't using version
1.5.3 with that patch. I found out that in "DefaultSettings.php" around line 1424 
$wgLinkWarn = false; 
has to be set instead of 
$wgLinkWarn = true;

also I found some error in SpecialWhatlinkshere.php around line 203: "Fatal
error: Call to a member function canAccessNamespace() on a non-object in
/var/www/html/wiki/includes/SpecialWhatlinkshere.php on line 203"
This can be eliminated by setting 
global $wgUser; 
around line 78, after function showIndirectLinks() begins.

Another error now occurs in SpecialRecentchangeslinked.php, an syntax error of
the sql statement. "1054: Unknown column 'page_namespace' in 'where clause'
(localhost)" I haven't had a closer look at it by now...
Comment 110 Dan Davis 2006-07-03 22:12:16 UTC
Created attachment 2045 [details]
Adds "your namespaces" to sidebar for 1.6.3.

Makes the restricted namespace patches more useful... shows a user a list of
namespaces to which they have access.
Comment 111 Dan Davis 2006-07-03 22:22:23 UTC
Created attachment 2046 [details]
Adds "your namespaces" to sidebar for 1.6.3

Makes the restricted namespace patches more useful by showing the user a list
of
namespaces to which they have access. If the user does not have access to any
restricted namespaces, the sidebar remains the standard.
Comment 112 Marco Rota 2006-07-05 14:41:36 UTC
(In reply to comment #108)
I've tried your workaround in a 1.5.6 installation and it work fine, but don't 
work in a 1.6.7.
What version you are using?
Comment 113 Roland Rosenfeld 2006-07-10 16:45:03 UTC
I found a little but in SpecialRecentchangeslinked: It uses the table
column page_namespace, but table 'page' isn't used in this query so it
fails.  Changing this to pl_namespace seems to solve this problem:

--- SpecialRecentchangeslinked.php.old	Mon Jul 10 18:32:17 2006
+++ SpecialRecentchangeslinked.php	Mon Jul 10 18:38:15 2006
@@ -67,7 +67,7 @@
 	if( is_array( $wgRestrictedNamespaces )) {
 		foreach( $wgRestrictedNamespaces as $key => $value ) {
 			if( ! $wgUser->canAccessNamespace( $key )) {
-				$cmq .= ' AND page_namespace <>' . $key;
+				$cmq .= ' AND pl_namespace <>' . $key;
 			}
 		}
 	}
Comment 114 Dan Davis 2006-07-13 18:17:21 UTC
Created attachment 2081 [details]
Updated for 1.7.1 (includes "your namespaces" in the sidebar)

As not able to include this snippet from a previous version into Parser.php. Do
not really understand it well enough to workout where it should go if it goes
at all.

***************
*** 2527,2532 ****
--- 2537,2546 ----
		if ( !$found ) {
			# Check for NS: (namespace expansion)
			$mwNs = MagicWord::get( MAG_NS );
+			  if ( $part1 == 'ns' ) {
+				  $text = $linestart . $wgContLang->getNsText(
$this->mTitle->getNamespace() );
+				  $found = true;
+			  }
			if ( $mwNs->matchStartAndRemove( $part1 ) ) {
				if ( intval( $part1 ) || $part1 == "0" ) {
					$text = $linestart .
$wgContLang->getNsText( intval( $part1 ) );
***************
Comment 115 Dan Davis 2006-07-13 18:30:02 UTC
Created attachment 2082 [details]
Updated for 1.7.1 (includes "your namespaces" in the sidebar)

Gah!!! Missed one line (in SpecialPreferences.php).
Comment 116 Dan Davis 2006-07-14 17:05:22 UTC
For v.1.7.1 patches.

Decided to put the sidebar heading into the database:

Create MediaWiki:Yournamespaces with your heading.

Update to includes/Skin.php, line 1494:
-  $heading = 'your namespaces';
+  $heading = wfMsgForContent ('yournamespaces');

Dan
Comment 117 Andreas Hubel 2006-07-16 16:46:43 UTC
I modified the restricted link feature. So with this changes it allows links
inside of the namespace group and not only the namespace as it was before.

includes/Parser.php
  			if( $wgLinkWarn && is_array( $wgRestrictedNamespaces )) {
- 				if( array_key_exists( $ns, $wgRestrictedNamespaces ) && 
($this->mTitle->getNamespace() != $ns)) {
+ 				if( array_key_exists( $ns, $wgRestrictedNamespaces ) && 
($this->mTitle->getNamespace() != $ns) && ($wgRestrictedNamespaces[$ns] !=
$wgRestrictedNamespaces[$this->mTitle->getNamespace()])) {
  					$s .=wfMsg( 'restrlink' ). $trail;
  					continue;
  				}
  			}
Comment 118 Dan Davis 2006-07-16 23:51:05 UTC
Andreas,

As the code existed prior to your changes, to enable linking into a restricted
namespace, you would set $wgLinkWarn = false; in LocalSettings.php. This would
allow those links.

Dan
Comment 119 Andreas Hubel 2006-07-17 06:45:02 UTC
I know. But I would like this feature, but i also want to link to the discussion
pages etc.

Andi
Comment 120 Dan Davis 2006-07-17 10:59:13 UTC
Anyone else find that after these patches, you can't undelete?

We found the cause in User.php (line 1321). Special:Undelete is protected and
itself includes a call to isAllowed('delete'). Therefore, the updated
isAllowed() function fails. We have updated line 1321 to check for portected
pages other than Special:Undelete. 

   //If the user wants to delete or undelete a page and it's blocked don't allow
him to do so.
   if( ($action == 'delete' || $action == 'undelete') &&
     ( ($title->isProtected() && !$title == "Special:Undelete" ) ||
$this->isBlocked()) ){
        return false;
   }

Dan
Comment 121 Andreas Hubel 2006-07-19 19:22:35 UTC
In our Wiki follow error occured:
Fatal error: Call to a member function on a non-object in
/webs/phpbb/root/www/phpbb.de/wiki/includes/SpecialWhatlinkshere.php on line 203

To fix this we did follow changes:

Modified: trunk/wiki/includes/SpecialWhatlinkshere.php
==============================================================================
--- trunk/wiki/includes/SpecialWhatlinkshere.php (original)
+++ trunk/wiki/includes/SpecialWhatlinkshere.php Mon Jul 17 02:21:18 2006
@@ -73,7 +73,7 @@
 	 * @access private
 	 */
 	function showIndirectLinks( $level, $target, $limit, $from = 0, $dir = 'next' ) {
-		global $wgOut;
+		global $wgOut, $wgUser;
 		$fname = 'WhatLinksHerePage::showIndirectLinks';
 
 		$dbr =& wfGetDB( DB_READ );
Comment 122 Andreas Hubel 2006-07-19 20:10:20 UTC
Oh I forgot:
Dan: Your undelete patch worked. The undelete function works now.
Comment 123 Jonathan Polley 2006-07-28 21:19:07 UTC
(In reply to comment #03)

You can not access the Special:Preferences page.  To do that, I had to remove
the patch at line 377 in SpecialPreferences.php.  This is not a problem with the
1.7.1 patch, but I have to use 1.6.x for a bit longer.
Comment 124 Octavi Estapé 2006-08-07 11:44:09 UTC
(In reply to comment #112)
> (In reply to comment #108)
> I've tried your workaround in a 1.5.6 installation and it work fine, but don't 
> work in a 1.6.7.
> What version you are using?
> 

I use 1.5.8 (with other patches). I won't upgrade for now because there are too
many changes.
I don't know if (in the patches for 1.6.x and 1.7.x) you can also see the
contents of a restricted page 

including it in a non restricted page: {{:RestrictedNS:NameOfThePage}}

Octavi
Comment 125 Joe Travaglini 2006-08-08 18:57:09 UTC
Octavi - 
  You will always be able to trans(in)clude a "restricted" page because the page
isn't truly "restricted".  These solutions are imperfect hacks.  This applies to
1.6.x and 1.7.x and will to 1.8.x as well.

  You will have to significantly modify the parser to handle the transclusion. 
And even then, there will still be aways around the restriction hacks.
Comment 126 Octavi Estapé 2006-08-09 08:16:49 UTC
(In reply to comment #125)
> Octavi - 
>   You will always be able to trans(in)clude a "restricted" page because the page
> isn't truly "restricted".  These solutions are imperfect hacks.  This applies to
> 1.6.x and 1.7.x and will to 1.8.x as well.
> 
>   You will have to significantly modify the parser to handle the transclusion. 
> And even then, there will still be aways around the restriction hacks.

I don't agree with you. Of course it won't be perfect (all the software has
imperfections), but I think that this patch is near to perfection. And I think
that our purpose is to make it better. I only found this problem and I think
that you won't find any way to see restricted content without the right
permission (at least in version 1.5.x). In case you do, please write it here.
Thanks!

Octavi
Comment 127 Didier Courtaud 2006-10-26 09:47:22 UTC
The proposed patch does not work with MW 1.8.2 :

patch -p1 < ../RS.patch
patching file includes/CategoryPage.php
Hunk #1 succeeded at 210 with fuzz 2 (offset 103 lines).
patching file includes/DefaultSettings.php
Hunk #1 succeeded at 1747 (offset 54 lines).
patching file includes/Export.php
Hunk #1 succeeded at 256 (offset 19 lines).
Hunk #2 succeeded at 355 (offset 19 lines).
patching file includes/OutputPage.php
Hunk #2 FAILED at 776.
1 out of 2 hunks FAILED -- saving rejects to file includes/OutputPage.php.rej
patching file includes/Parser.php
Hunk #1 FAILED at 1508.
Hunk #2 FAILED at 2826.
2 out of 2 hunks FAILED -- saving rejects to file includes/Parser.php.rej
patching file includes/QueryPage.php
patching file includes/SearchEngine.php
Hunk #1 succeeded at 167 (offset 5 lines).
patching file includes/SpecialAllpages.php
patching file includes/SpecialContributions.php
patching file includes/SpecialLog.php
patching file includes/SpecialPreferences.php
Hunk #2 succeeded at 384 (offset 5 lines).
Hunk #3 FAILED at 394.
1 out of 3 hunks FAILED -- saving rejects to file
includes/SpecialPreferences.php.rej
patching file includes/SpecialRandompage.php
patching file includes/SpecialRecentchanges.php
patching file includes/SpecialRecentchangeslinked.php
patching file includes/SpecialUserlogin.php
Hunk #1 succeeded at 475 (offset 34 lines).
Hunk #2 succeeded at 485 (offset 34 lines).
patching file includes/SpecialWantedpages.php
patching file includes/SpecialWhatlinkshere.php
patching file includes/Title.php
Hunk #1 succeeded at 1026 (offset -4 lines).
Hunk #2 succeeded at 1137 (offset -3 lines).
Hunk #3 succeeded at 1151 (offset -3 lines).
patching file includes/User.php
Hunk #1 FAILED at 1237.
1 out of 1 hunk FAILED -- saving rejects to file includes/User.php.rej
patching file includes/Skin.php
Hunk #1 FAILED at 1445.
Hunk #2 succeeded at 1558 (offset 67 lines).
1 out of 2 hunks FAILED -- saving rejects to file includes/Skin.php.rej

Does anyone can publish a version compatible with MW 1.8.2

Didier
Comment 128 Joseph Southwell 2006-11-09 22:21:07 UTC
Created attachment 2667 [details]
Updated for 2082 for 1.8.2

I updated for 1.8.2
I made very few changes 
1.
-#if( $this->canAccessNamespace($nsid) && !($nsid %2) ) { 
+if( $this->canAccessNamespace($nsid) ) {
all I could see the %2 doing was removing odd numbered namespace ids from the
list. I could not imagine a reason to do that. 

2. altered the formatting of the restricted namespace list on the UserLogin
page. 

3. added a bunch of default rights to the sysop user. I had group user very
limitted and sysop couldn't do anything because it was expecting to inherit
some of its authority from user.
Comment 129 Rob Church 2006-11-09 23:00:57 UTC
Can future patches for this hack be maintained/distributed elsewhere? I ask
because each individual problem/notification clogs up the inboxes of people
who'd rather not receive the emails. In addition, using our bug tracker gives
off the false impressions that (a) this is going to make it into MediaWiki *some
time*, even though it's not, no matter how much Santa Claus begs, and (b) that
we're in some means affiliated with it.

I'm sure someone out there would be willing to host discussion like this for
what amounts to a major fork in aims and scope of MediaWiki.
Comment 130 Joseph Southwell 2006-11-10 20:53:09 UTC
I have fixed one bug and added 2 features to the patch for 1.8.2. Per Rob
Church's request above the current state of my version of the patch can be had at

<a
href="http://wiki.ontoserve.com/index.php/Namespace_Hack">http://wiki.ontoserve.com/index.php/Namespace_Hack</a>
Comment 131 Noel 2006-12-08 09:33:47 UTC
Created attachment 2838 [details]
Updated for 1.8.2 (two bugs fixed)
Comment 132 Ben Levitt 2006-12-23 01:26:08 UTC
*** Bug 8360 has been marked as a duplicate of this bug. ***
Comment 133 qsheets095 2007-01-02 00:15:20 UTC
Comment on attachment 2838 [details]
Updated for 1.8.2 (two bugs fixed)

>diff -iEbdu -r ./includes/Article.php ./includes/Article.php
>--- ./includes/Article.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/Article.php	2006-12-07 15:30:54.340034100 +0100
>@@ -644,7 +644,6 @@
> 
> 		# If we got diff and oldid in the query, we want to see a
> 		# diff page instead of the article.
>-
> 		if ( !is_null( $diff ) ) {
> 			$wgOut->setPageTitle( $this->mTitle->getPrefixedText() );
> 
>diff -iEbdu -r ./includes/CategoryPage.php ./includes/CategoryPage.php
>--- ./includes/CategoryPage.php	2006-11-21 16:36:14.472026700 +0100
>+++ ./includes/CategoryPage.php	2006-12-07 15:22:52.721070900 +0100
>@@ -175,6 +175,7 @@
> 	}
> 
> 	function doCategoryQuery() {
>+		global $wgUser;
> 		$dbr =& wfGetDB( DB_SLAVE );
> 		if( $this->from != '' ) {
> 			$pageCondition = 'cl_sortkey >= ' . $dbr->addQuotes( $this->from );
>@@ -210,6 +211,11 @@
> 
> 			$title = Title::makeTitle( $x->page_namespace, $x->page_title );
> 
>+			# If this page is inside a restricted namespace, skip the result...
>+ 			if(!$wgUser->canAccessNamespace($title->getNamespace())) {
>+ 				continue;
>+ 			}
>+
> 			if( $title->getNamespace() == NS_CATEGORY ) {
> 				$this->addSubcategory( $title, $x->cl_sortkey, $x->page_len );
> 			} elseif( $title->getNamespace() == NS_IMAGE ) {
>diff -iEbdu -r ./includes/DefaultSettings.php ./includes/DefaultSettings.php
>--- ./includes/DefaultSettings.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/DefaultSettings.php	2006-12-07 15:30:58.121429300 +0100
>@@ -914,6 +914,13 @@
> $wgGroupPermissions['bot'  ]['autoconfirmed']   = true;
> 
> // Most extra permission abilities go to this group
>+$wgGroupPermissions['sysop']['createpage']      = true;
>+$wgGroupPermissions['sysop']['createtalk']      = true;
>+$wgGroupPermissions['sysop']['read']            = true;
>+$wgGroupPermissions['sysop']['edit']            = true;
>+$wgGroupPermissions['sysop']['minoredit']       = true;
>+$wgGroupPermissions['sysop']['roread']          = true;
>+$wgGroupPermissions['sysop']['roedit']          = true;
> $wgGroupPermissions['sysop']['block']           = true;
> $wgGroupPermissions['sysop']['createaccount']   = true;
> $wgGroupPermissions['sysop']['delete']          = true;
>@@ -1747,6 +1754,96 @@
> $wgExtraNamespaces = NULL;
> 
> /**
>+ * Hidden namespaces. If you include a namespace in this array, only users with
>+ * the matching priviledges will be able to see and edit pages in this
>+ * namespace.
>+ *
>+ * The form is " namespace => 'priviledge' " e.g.
>+ *
>+ * $wgRestrictedNamespaces =
>+ *    array(100 => 'coolguy',
>+ *             101 => 'coolguy'
>+ *            );
>+ *
>+ * where 100 is the namespace id and 'coolguy' is the priviledge.
>+ *
>+ * Each priv. is a string in an array, you can add as many as you like
>+ * in the $wgGroupPermitions array e.g.
>+ *
>+ *$wgGroupPermissions['allowed']['coolguy'] = true;
>+ *
>+ * In this example you asigned the 'coolguy' priviledge to the 'allowed' group.
>+ *
>+ */
>+$wgRestrictedNamespaces = NULL;
>+
>+/**
>+ * In case you want only to deny the edit right on a namespace, you may put it
>+ * in this array. You also need to asign the 'roread' right to the usergroup you
>+ * want to be able to read and the 'roedit' right to the usergroup you want to be
>+ * able to edit. Read only namespaces are not hiden (nor their logs etc).
>+ *
>+ * Example: $wgReadOnlyNSes = array(100,101);
>+ *
>+ */
>+$wgReadOnlyNSes = NULL;
>+
>+/**
>+ * In case you have categories of pages located on a restricted namespaces
>+ * those categories will appear empty and might be comfusing. Setting this
>+ * var to true, (all) categories will be hidden in the Recent changes.
>+ */
>+$wgHideCategoriesinRC = false;
>+
>+/**
>+ * Logs in Recent Changes are treated all the same, so normaly users will be able
>+ * to see moves, protects and deletes of pages in restricted namespaces. Setting
>+ * this var to true will hide all logs in Recent Changes and only those for restricted
>+ * namespaces in Special:Log.
>+ */
>+$wgHideLogs = false;
>+ 
>+/**
>+ * In case you want to customize what logs the user can see both in Recent Changes
>+ * and Special:Log, modify this array to include the log types you want to hide. This is
>+ * overriden by $wgHideLogs for Recent Changes and those logs for restricted
>+ * namespaces in Special:Log. This feature lets you hide also the 'block' and 'rights'
>+ * log types that are namespace independed in Special:Log, or show them in RC while
>+ * hiding the rest.
>+ * 
>+ * This example shows how to hide all log types in RC, and (block/rights) in Special:Log
>+ * (the others in Special:Log are  are filtered based on namespace access rights so they
>+ * apply only for restricted namespaces).
>+ *
>+ *$wgHidenLogs = array('block','protect', 'rights', 'delete','upload', 'move');
>+ */
>+$wgHidenLogs = NULL;
>+ 
>+/**
>+ * In case some user tries to create a link from some namespace to an other restricted
>+ * namespace, while the page gets parsed, instead of the link, a warning message will appear
>+ * ('restrlink') to let the user know. If the link is in the same namespace as the edited page,
>+ * no check will be done.
>+ */
>+$wgLinkWarn = true; 
>+ 
>+/**
>+ * In case you want to hide logs about User Talk pages (namespace 3) fromnrecent changes
>+ * set this to true.
>+ * 
>+ */
>+$wgHideUtalk = false; 
>+ 
>+/**
>+ * You can use this array to alter wiki's upper left logo depending on the namespace
>+ * you are in. 
>+ *
>+ * Example:
>+ * $wgNamespaceLogos = array ( 100 => '/url_path_to/logo.gif');
>+ **/
>+$wgNamespaceLogos = NULL;
>+
>+/**
>  * Limit images on image description pages to a user-selectable limit. In order
>  * to reduce disk usage, limits can only be selected from a list. This is the
>  * list of settings the user can choose from:
>diff -iEbdu -r ./includes/Export.php ./includes/Export.php
>--- ./includes/Export.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/Export.php	2006-12-07 15:30:56.355736500 +0100
>@@ -256,7 +256,13 @@
> 	 */
> 	function outputStream( $resultset ) {
> 		$last = null;
>+		global $wgUser;
> 		while( $row = $resultset->fetchObject() ) {
>+                        #If page is in a secured namespace, skip the row.
>+                        if(!$wgUser->canAccessNamespace($row->page_namespace) ){
>+                               continue;
>+                        }
>+
> 			if( is_null( $last ) ||
> 				$last->page_namespace != $row->page_namespace ||
> 				$last->page_title     != $row->page_title ) {
>@@ -349,11 +355,14 @@
> 	}
> 
> 	function namespaces() {
>-		global $wgContLang;
>-		$spaces = "  <namespaces>\n";
>+		global $wgContLang, $wgUser;
>+		$spaces = "<namespaces>\n";
> 		foreach( $wgContLang->getFormattedNamespaces() as $ns => $title ) {
>+			if($wgUser->canAccessNamespace($ns))
>+			{
> 			$spaces .= '      ' . wfElement( 'namespace', array( 'key' => $ns ), $title ) . "\n";
> 		}
>+		}
> 		$spaces .= "    </namespaces>";
> 		return $spaces;
> 	}
>diff -iEbdu -r ./includes/OutputPage.php ./includes/OutputPage.php
>--- ./includes/OutputPage.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/OutputPage.php	2006-12-07 15:30:56.636997300 +0100
>@@ -236,7 +236,7 @@
> 		foreach ( $categories as $category => $arbitrary ) {
> 			$title = Title::makeTitleSafe( NS_CATEGORY, $category );
> 			$text = $wgContLang->convertHtml( $title->getText() );
>-			$this->mCategoryLinks[] = $sk->makeLinkObj( $title, $text );
>+			$this->mCategoryLinks[] = $sk->makeKnownLinkObj( $title, $text );
> 		}
> 	}
> 
>@@ -723,6 +723,7 @@
> 		$this->mBodytext = '';
> 
> 		$groups = array();
>+		
> 		foreach( $wgGroupPermissions as $key => $value ) {
> 			if( isset( $value[$permission] ) && $value[$permission] == true ) {
> 				$groupName = User::getGroupName( $key );
>@@ -777,6 +778,21 @@
> 
> 		$skin = $wgUser->getSkin();
> 		
>+		if($wgTitle->getNamespace() >= 100){
>+ 			$usersNamespaces = $wgUser->getAllowedRNSes();
>+ 			$usersNamespacesArray = explode("\n", $usersNamespaces);
>+ 			$currentNamespace = Namespace::getCanonicalName($wgTitle->getNamespace());
>+ 
>+ 			if (!in_array($currentNamespace, $usersNamespacesArray)) {
>+ 				$this->setPageTitle( wfMsg( 'noaccesstitle' ) );
>+ 				$this->setHtmlTitle( wfMsg( 'errorpagetitle' ) );
>+ 				$this->setRobotPolicy( 'noindex,nofollow' );
>+ 				$this->setArticleFlag( false );
>+ 				$this->addHTML( wfMsgHtml( 'noaccesstext') );
>+ 			} else {
>+ 				// Should never reach here.
>+ 			}
>+		} else {
> 		$this->setPageTitle( wfMsg( 'loginreqtitle' ) );
> 		$this->setHtmlTitle( wfMsg( 'errorpagetitle' ) );
> 		$this->setRobotPolicy( 'noindex,nofollow' );
>@@ -793,6 +809,7 @@
> 		if( $mainPage->userCanRead() )
> 			$this->returnToMain( true, $mainPage );
> 	}
>+	}
> 
> 	/** @obsolete */
> 	function databaseError( $fname, $sql, $error, $errno ) {
>diff -iEbdu -r ./includes/Parser.php ./includes/Parser.php
>--- ./includes/Parser.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/Parser.php	2006-12-07 16:39:15.760002900 +0100
>@@ -1463,6 +1463,7 @@
> 	 */
> 	function replaceInternalLinks( $s ) {
> 		global $wgContLang;
>+		global $wgUser;
> 		static $fname = 'Parser::replaceInternalLinks' ;
> 
> 		wfProfileIn( $fname );
>@@ -1604,6 +1605,17 @@
> 
> 			$ns = $nt->getNamespace();
> 			$iw = $nt->getInterWiki();
>+
>+ 			#If the link points to a restricted namespace outside the
>+ 			#parent namespace warn the user.
>+ 			global $wgRestrictedNamespaces, $wgLinkWarn ;
>+ 			if( $wgLinkWarn && is_array( $wgRestrictedNamespaces )) {
>+ 				if( array_key_exists( $ns, $wgRestrictedNamespaces ) &&  !$wgUser->canAccessNamespace( $ns )) {/*($this->mTitle->getNamespace() != $ns)) {*/
>+ 					$s .=wfMsg( 'restrlink' ). $trail;
>+ 					continue;
>+ 				}
>+ 			}
>+
> 			wfProfileOut( "$fname-title" );
> 			
> 			if ($might_be_img) { # if this is actually an invalid link
>@@ -2826,7 +2838,7 @@
> 	 * @private
> 	 */
> 	function braceSubstitution( $piece ) {
>-		global $wgContLang, $wgLang, $wgAllowDisplayTitle, $action;
>+		global $wgContLang, $wgLang, $wgAllowDisplayTitle, $action, $wgRestrictedNamespaces;
> 		$fname = __METHOD__ /*. '-L' . count( $this->mArgStack )*/;
> 		wfProfileIn( $fname );
> 		wfProfileIn( __METHOD__.'-setup' );
>@@ -2994,6 +3006,15 @@
> 				}
> 
> 				if ( !$title->isExternal() ) {
>+					# Articles from restricted namespaces can't be used in templates.
>+					# They would appear or disappear based on the rights of the user
>+					# that refreshes the cache...
>+					if( is_array( $wgRestrictedNamespaces ) ) {
>+						if( array_key_exists( $title->getNamespace(), $wgRestrictedNamespaces ) ) {
>+							$found = true;
>+							$text = $linestart . wfMsg( 'templatenotincluded' );
>+						}
>+ 					}
> 					if ( $title->getNamespace() == NS_SPECIAL && $this->mOptions->getAllowSpecialInclusion() && $this->ot['html'] ) {
> 						$text = SpecialPage::capturePath( $title );
> 						if ( is_string( $text ) ) {
>diff -iEbdu -r ./includes/QueryPage.php ./includes/QueryPage.php
>--- ./includes/QueryPage.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/QueryPage.php	2006-12-07 15:30:58.355813300 +0100
>@@ -474,8 +474,14 @@
> class PageQueryPage extends QueryPage {
> 
> 	function formatResult( $skin, $result ) {
>-		global $wgContLang;
>+		global $wgContLang, $wgUser;
> 		$nt = Title::makeTitle( $result->namespace, $result->title );
>+
>+		# Don't show wanted pages in restricted namespaces
>+		if( !$wgUser->canAccessNamespace( $nt->getNamespace() ) ) {
>+			return "";
>+		}
>+
> 		return $skin->makeKnownLinkObj( $nt, htmlspecialchars( $wgContLang->convert( $nt->getPrefixedText() ) ) );
> 	}
> }
>diff -iEbdu -r ./includes/SearchEngine.php ./includes/SearchEngine.php
>--- ./includes/SearchEngine.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/SearchEngine.php	2006-12-07 16:12:19.098684900 +0100
>@@ -167,10 +167,10 @@
> 	 * @access public
> 	 */
> 	function searchableNamespaces() {
>-		global $wgContLang;
>+		global $wgContLang, $wgUser;
> 		$arr = array();
> 		foreach( $wgContLang->getNamespaces() as $ns => $name ) {
>-			if( $ns >= NS_MAIN ) {
>+			if( $ns >= NS_MAIN && $wgUser->canAccessNamespace($ns)) {
> 				$arr[$ns] = $name;
> 			}
> 		}
>diff -iEbdu -r ./includes/Skin.php ./includes/Skin.php
>--- ./includes/Skin.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/Skin.php	2006-12-07 15:41:43.918198000 +0100
>@@ -121,7 +121,6 @@
> 		include_once( "{$wgStyleDirectory}/{$skinName}.deps.php" );
> 		wfRestoreWarnings();
> 		require_once( "{$wgStyleDirectory}/{$skinName}.php" );
>-
> 		# Check if we got if not failback to default skin
> 		$className = 'Skin'.$skinName;
> 		if( !class_exists( $className ) ) {
>@@ -1511,11 +1510,22 @@
> 	 */
> 	function buildSidebar() {
> 		global $parserMemc, $wgEnableSidebarCache;
>-		global $wgLang, $wgContLang;
>+		global $wgLang, $wgContLang, $wgUser, $wgTitle;
>+		global $wgExtraNamespaces, $wgRestrictedNamespaces;
> 
> 		$fname = 'SkinTemplate::buildSidebar';
> 
> 		wfProfileIn( $fname );
>+		$nsname = '';
>+		if(is_object($wgTitle))
>+		{
>+			$nsid = $wgTitle->getNamespace();
>+			if(in_array($nsid, array_keys($wgExtraNamespaces)) && 
>+				in_array($nsid, array_keys($wgRestrictedNamespaces)))
>+			{	
>+				$nsname = $wgExtraNamespaces[$nsid].":";	
>+			}
>+		}
> 
> 		$key = wfMemcKey( 'sidebar' );
> 		$cacheSidebar = $wgEnableSidebarCache &&
>@@ -1550,13 +1560,28 @@
> 					$href = self::makeInternalOrExternalUrl( $link );
> 					$bar[$heading][] = array(
> 						'text' => $text,
>-						'href' => $href,
>+						'href' => preg_replace('/Main_Page$/', $nsname."Main_Page", $href),
> 						'id' => 'n-' . strtr($line[1], ' ', '-'),
> 						'active' => false
> 					);
> 				} else { continue; }
> 			}
> 		}
>+		$heading = 'your namespaces';
>+ 		$lines = explode( "\n", $wgUser->getAllowedRNSes() );
>+ 		if (count($lines) > 0 && $lines[0] != '') {
>+ 			foreach ($lines as $line) {
>+ 				$bar[$heading][] = array(
>+ 					'text' => $line,
>+ 					'href' => $this->makeInternalOrExternalUrl( $line . ':' . wfMsgForContent( 'mainpage' ) ),
>+ 					'id' => 'n-' . strtr($line, ' ', '-'),
>+ 					'active' => false
>+ 				);
>+ 			}
>+ 		}
>+
> 		if ($cacheSidebar)
> 			$cachednotice = $parserMemc->set( $key, $bar, 86400 );
> 		wfProfileOut( $fname );
>diff -iEbdu -r ./includes/SkinTemplate.php ./includes/SkinTemplate.php
>--- ./includes/SkinTemplate.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/SkinTemplate.php	2006-12-07 15:41:43.918198000 +0100
>@@ -1076,7 +1076,12 @@
>	 */
>	function text( $str ) {
>-		echo htmlspecialchars( $this->data[$str] );
>+		global $wgTitle, $wgNamespaceLogos;
>+		if('logopath'==$str && isset($wgNamespaceLogos[$wgTitle->getNamespace()])) {
>+			echo htmlspecialchars( $wgNamespaceLogos[$wgTitle->getNamespace()] );
>+		} else {
>+			echo htmlspecialchars( $this->data[$str] );
>+		}
>	}
>
>	/**
>	 * @private
>diff -iEbdu -r ./includes/SpecialAllpages.php ./includes/SpecialAllpages.php
>--- ./includes/SpecialAllpages.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/SpecialAllpages.php	2006-12-07 15:21:46.970229300 +0100
>@@ -10,17 +10,24 @@
>  * @param $specialPage @see SpecialPage object.
>  */
> function wfSpecialAllpages( $par=NULL, $specialPage ) {
>-	global $wgRequest, $wgOut, $wgContLang;
>+	global $wgRequest, $wgOut, $wgContLang, $wgUser;
> 
> 	# GET values
> 	$from = $wgRequest->getVal( 'from' );
> 	$namespace = $wgRequest->getInt( 'namespace' );
> 
> 	$namespaces = $wgContLang->getNamespaces();
>+ 	if ( isset($par) ) {
>+ 		foreach ($namespaces as $ns_id => $ns_name) {
>+ 			if ($par == $ns_name) {
>+ 				$namespace = $ns_id;
>+ 			}
>+ 		}
>+ 	}
> 
> 	$indexPage = new SpecialAllpages();
> 
>-	if( !in_array($namespace, array_keys($namespaces)) )
>+ 	if( !in_array($namespace, array_keys($namespaces)) || !$wgUser->canAccessNamespace( $namespace))
> 		$namespace = 0;
> 
> 	$wgOut->setPagetitle( $namespace > 0 ?
>@@ -28,9 +35,7 @@
> 		wfMsg( 'allarticles' )
> 		);
> 
>-	if ( isset($par) ) {
>-		$indexPage->showChunk( $namespace, $par, $specialPage->including() );
>-	} elseif ( isset($from) ) {
>+	if ( isset($from) ) {
> 		$indexPage->showChunk( $namespace, $from, $specialPage->including() );
> 	} else {
> 		$indexPage->showToplevel ( $namespace, $specialPage->including() );
>diff -iEbdu -r ./includes/SpecialContributions.php ./includes/SpecialContributions.php
>--- ./includes/SpecialContributions.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/SpecialContributions.php	2006-12-07 15:30:56.136978100 +0100
>@@ -16,7 +16,14 @@
> 	}
> 
> 	function setNamespace( $ns ) {
>+		global $wgUser;
>+		# If the namespace asked is restricted return
>+		# to the main namespace.
>+		if($wgUser->canAccessNamespace($ns)) {
> 		$this->namespace = $ns;
>+		}else{
>+			$this->namespace = 0;
>+		}
> 	}
> 
> 	function setLimit( $limit ) {
>@@ -72,15 +79,30 @@
> 	}
> 
> 	function getNamespaceCond() {
>-		if ( $this->namespace !== false )
>+		global $wgUser;
>+		# Include the namespace in the querry only if it's not restricted to the user.
>+		if (($this->namespace !== false) && ($wgUser->canAccessNamespace($this->namespace))) {
> 			return ' AND page_namespace = ' . (int)$this->namespace;
>+		} else {
> 		return '';
> 	}
>+	}
> 
> 	function getPreviousOffsetForPaging() {
> 		list( $index, $usercond ) = $this->getUserCond();
> 		$nscond = $this->getNamespaceCond();
> 
>+		# Exclude all namespaces that are restricted to this user
>+		global $wgRestrictedNamespaces;
>+		global $wgUser;
>+		if( is_array( $wgRestrictedNamespaces )) {
>+			foreach( $wgRestrictedNamespaces as $key => $value ) {
>+				if( ! $wgUser->canAccessNamespace( $key )) {
>+					$nscond .= ' AND page_namespace <>' . $key;
>+				}
>+			}
>+		}
>+
> 		$use_index = $this->dbr->useIndexClause( $index );
> 		extract( $this->dbr->tableNames( 'page', 'revision' ) );
> 
>@@ -137,6 +159,16 @@
> 			$offsetQuery = "AND rev_timestamp <= '{$this->offset}'";
> 
> 		$nscond = $this->getNamespaceCond();
>+		# Exclude all namespaces that are restricted to this user
>+		global $wgRestrictedNamespaces;
>+		global $wgUser;
>+		if( is_array( $wgRestrictedNamespaces )) {
>+			foreach( $wgRestrictedNamespaces as $key => $value ) {
>+				if( ! $wgUser->canAccessNamespace( $key )) {
>+					$nscond .= ' AND page_namespace <>' . $key;
>+				}
>+			}
>+		}
> 		$use_index = $this->dbr->useIndexClause( $index );
> 		$sql = "SELECT
> 			page_namespace,page_title,page_is_new,page_latest,
>diff -iEbdu -r ./includes/SpecialLog.php ./includes/SpecialLog.php
>--- ./includes/SpecialLog.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/SpecialLog.php	2006-12-07 15:30:57.433902900 +0100
>@@ -302,11 +302,42 @@
> 	 * @private
> 	 */
> 	function logLine( $s ) {
>-		global $wgLang;
>+		global $wgLang, $wgUser;
>+		global $wgHideLogs, $wgHidenLogs;
> 		$title = Title::makeTitle( $s->log_namespace, $s->log_title );
> 		$user = Title::makeTitleSafe( NS_USER, $s->user_name );
> 		$time = $wgLang->timeanddate( wfTimestamp(TS_MW, $s->log_timestamp), true );
> 
>+ 		# Hide all logs or the log types in $wgHidenLogs.
>+ 		# Block and rights are namespace independed.
>+ 		if((is_array($wgHidenLogs) &&
>+ 			((in_array('block', $wgHidenLogs) && $s->log_type =='block' )
>+ 			||(in_array('rights', $wgHidenLogs) && $s->log_type=='rights'))
>+ 			||($wgHideLogs && ($s->log_type=='block' ||$s->log_type=='rights')))){
>+ 				return;
>+ 		}
>+ 
>+ 		# Upload namespaces are public.
>+ 		if(is_array($wgHidenLogs) &&
>+ 			(in_array('upload', $wgHidenLogs) && $s->log_type=='upload') ||
>+ 			($wgHideLogs && $s->log_type=='upload')) {
>+ 				return;
>+ 		}
>+ 
>+ 		# We hide the rest only for the restricted namespaces.
>+ 		if(!$wgUser->canAccessNamespace($s->log_namespace)){
>+ 			if($wgHideLogs){
>+ 				return;
>+ 			}
>+ 			if(is_array($wgHidenLogs)){
>+ 				if((in_array('protect', $wgHidenLogs) && $s->log_type=='protect')
>+ 					||(in_array('delete', $wgHidenLogs) && $s->log_type=='delete')
>+ 					||(in_array('move', $wgHidenLogs) && $s->log_type=='move')){
>+ 						return;
>+ 				}
>+ 			}
>+ 		}
>+
> 		// Enter the existence or non-existence of this page into the link cache,
> 		// for faster makeLinkObj() in LogPage::actionText()
> 		$linkCache =& LinkCache::singleton();
>diff -iEbdu -r ./includes/SpecialPreferences.php ./includes/SpecialPreferences.php
>--- ./includes/SpecialPreferences.php	2006-12-07 11:51:17.164600800 +0100
>+++ ./includes/SpecialPreferences.php	2006-12-07 15:30:57.730789300 +0100
>@@ -88,7 +88,7 @@
> 		if ( $this->mPosted ) {
> 			$namespaces = $wgContLang->getNamespaces();
> 			foreach ( $namespaces as $i => $namespace ) {
>-				if ( $i >= 0 ) {
>+				if ( $i >= 0 && $wgUser->canAccessNamespace( $i) ) {
> 					$this->mSearchNs[$i] = $request->getCheck( "wpNs$i" ) ? 1 : 0;
> 				}
> 			}
>@@ -384,7 +384,7 @@
> 
> 		$namespaces = $wgContLang->getNamespaces();
> 		foreach ( $namespaces as $i => $namespace ) {
>-			if ( $i >= NS_MAIN ) {
>+			if ( $i >= NS_MAIN && $wgUser->canAccessNamespace( $i) ) {
> 				$this->mSearchNs[$i] = $wgUser->getOption( 'searchNs'.$i );
> 			}
> 		}
>@@ -394,14 +394,14 @@
> 	 * @access private
> 	 */
> 	function namespacesCheckboxes() {
>-		global $wgContLang;
>+		global $wgContLang, $wgUser;
> 
> 		# Determine namespace checkboxes
> 		$namespaces = $wgContLang->getNamespaces();
> 		$r1 = null;
> 
> 		foreach ( $namespaces as $i => $name ) {
>-			if ($i < 0)
>+			if ($i < 0 || !$wgUser->canAccessNamespace( $i) )
> 				continue;
> 			$checked = $this->mSearchNs[$i] ? "checked='checked'" : '';
> 			$name = str_replace( '_', ' ', $namespaces[$i] );
>diff -iEbdu -r ./includes/SpecialRandompage.php ./includes/SpecialRandompage.php
>--- ./includes/SpecialRandompage.php	2006-10-14 02:06:36.000000000 +0200
>+++ ./includes/SpecialRandompage.php	2006-12-07 15:30:59.058965300 +0100
>@@ -11,12 +11,15 @@
>  *               used as e.g. Special:Randompage/Category
>  */
> function wfSpecialRandompage( $par = NS_MAIN ) {
>-	global $wgOut, $wgExtraRandompageSQL, $wgContLang, $wgLang;
>+	global $wgOut, $wgExtraRandompageSQL, $wgContLang, $wgLang, $wgUser;
> 	$fname = 'wfSpecialRandompage';
> 
> 	# Determine namespace
> 	$t = Title::newFromText ( $par . ":Dummy" ) ;
> 	$namespace = $t->getNamespace () ;
>+ 	if ($namespace === false || $namespace < NS_MAIN || !$wgUser->canAccessNamespace($namespace)) {
>+ 		$namespace = NS_MAIN;
>+ 	}
> 
> 	# NOTE! We use a literal constant in the SQL instead of the RAND()
> 	# function because RAND() will return a different value for every row
>diff -iEbdu -r ./includes/SpecialRecentchanges.php ./includes/SpecialRecentchanges.php
>--- ./includes/SpecialRecentchanges.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/SpecialRecentchanges.php	2006-12-07 15:30:55.011934900 +0100
>@@ -17,6 +17,7 @@
> 	global $wgUser, $wgOut, $wgRequest, $wgUseRCPatrol, $wgDBtype;
> 	global $wgRCShowWatchingUsers, $wgShowUpdatedMarker;
> 	global $wgAllowCategorizedRecentChanges ;
>+	global $wgRestrictedNamespaces, $wgHideCategoriesinRC, $wgHidenLogs, $wgHideLogs, $wgHideUtalk;
> 	$fname = 'wfSpecialRecentchanges';
> 
> 	# Get query parameters
>@@ -124,8 +125,9 @@
> 
> 	# Get last modified date, for client caching
> 	# Don't use this if we are using the patrol feature, patrol changes don't update the timestamp
>+	# Don't use it if there are hidden namespaces, as the feed must be different for the users
> 	$lastmod = $dbr->selectField( 'recentchanges', 'MAX(rc_timestamp)', false, $fname );
>-	if ( $feedFormat || !$wgUseRCPatrol ) {
>+	if ( !is_array( $wgRestrictedNamespaces ) && ($feedFormat || !$wgUseRCPatrol) ) {
> 		if( $lastmod && $wgOut->checkLastModified( $lastmod ) ){
> 			# Client cache fresh and headers sent, nothing more to do.
> 			return;
>@@ -152,6 +154,32 @@
> 		}
> 	}
> 
>+ 	# Hide all categories if $wgHideCategoriesinRC is set
>+ 	$hidem .= $wgHideCategoriesinRC ? ' AND rc_namespace <> 14':'';
>+ 	# Hide all User_talk pages if $wgHideUtalk is set
>+ 	$hidem .= $wgHideUtalk ? ' AND rc_namespace <> 3':'';
>+ 	# Hide all logs if $wgHideRCLogs is set
>+ 	$hidem .= $wgHideLogs ? ' AND rc_type <> 3':'';
>+ 	# Hide all logs or the log types in $wgHidenLogs.
>+ 	if(!$wgHideLogs && is_array($wgHidenLogs)){
>+ 		# Block and rights are namespace independed.
>+ 		$hidem .= in_array('block', $wgHidenLogs) ? ' AND rc_title <> "Log/block"':'';
>+ 		$hidem .= in_array('rights', $wgHidenLogs) ? ' AND rc_title <> "Log/rights"':'';
>+ 		# Hide the log types set in $wgHidenLogs
>+ 		$hidem .= in_array('protect', $wgHidenLogs) ? ' AND rc_title <> "Log/protect"':'';
>+ 		$hidem .= in_array('delete', $wgHidenLogs) ? ' AND rc_title <> "Log/delete"':'';
>+ 		$hidem .= in_array('upload', $wgHidenLogs) ? ' AND rc_title <> "Log/upload"':'';
>+ 		$hidem .= in_array('move', $wgHidenLogs) ? ' AND rc_title <> "Log/move"':'';
>+ 	}
>+ 	# Exclude all namespaces that are restricted to this user
>+ 	if( is_array( $wgRestrictedNamespaces )) {
>+ 		foreach( $wgRestrictedNamespaces as $key => $value ) {
>+ 			if( ! $wgUser->canAccessNamespace( $key )) {
>+ 				$hidem .= ' AND rc_namespace <>' . $key;
>+ 			}
>+ 		}
>+ 	}
>+
> 	# Namespace filtering
> 	$hidem .= is_null( $namespace ) ?  '' : ' AND rc_namespace' . ($invert ? '!=' : '=') . $namespace;
> 
>@@ -349,8 +377,13 @@
> 		 * go ahead and use it even if there have been edits made
> 		 * since it was rendered. This keeps a swarm of requests
> 		 * from being too bad on a super-frequently edited wiki.
>+		 *
>+		 * Using restricted namespaces forbids caching the feed,
>+		 * however, since it must be rendered according to user
>+		 * rights.
> 		 */
>-		if( time() - wfTimestamp( TS_UNIX, $feedLastmod )
>+		if( !is_array( $wgRestrictedNamespaces )
>+			&& time() - wfTimestamp( TS_UNIX, $feedLastmod )
> 				< $wgFeedCacheTimeout
> 			|| wfTimestamp( TS_UNIX, $feedLastmod )
> 				> wfTimestamp( TS_UNIX, $lastmod ) ) {
>diff -iEbdu -r ./includes/SpecialRecentchangeslinked.php ./includes/SpecialRecentchangeslinked.php
>--- ./includes/SpecialRecentchangeslinked.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/SpecialRecentchangeslinked.php	2006-12-07 15:22:21.173792100 +0100
>@@ -67,6 +67,16 @@
> 		$cmq = 'AND rc_minor=0';
> 	} else { $cmq = ''; }
> 
>+	# Exclude all namespaces that are restricted to this user
>+ 	global $wgRestrictedNamespaces;
>+ 	if( is_array( $wgRestrictedNamespaces )) {
>+ 		foreach( $wgRestrictedNamespaces as $key => $value ) {
>+ 			if( ! $wgUser->canAccessNamespace( $key )) {
>+ 				$cmq .= ' AND page_namespace <>' . $key;
>+ 			}
>+ 		}
>+ 	}
>+
> 	extract( $dbr->tableNames( 'recentchanges', 'categorylinks', 'pagelinks', 'revision', 'page' , "watchlist" ) );
> 
> 	$uid = $wgUser->getID();
>diff -iEbdu -r ./includes/SpecialUserlogin.php ./includes/SpecialUserlogin.php
>--- ./includes/SpecialUserlogin.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/SpecialUserlogin.php	2006-12-07 15:30:54.574418100 +0100
>@@ -475,6 +475,7 @@
> 	function successfulLogin( $msg, $auto = true ) {
> 		global $wgUser;
> 		global $wgOut;
>+		global $wgLinkWarn;
> 
> 		# Run any hooks; ignore results
> 
>@@ -484,12 +485,20 @@
> 		$wgOut->setRobotpolicy( 'noindex,nofollow' );
> 		$wgOut->setArticleRelated( false );
> 		$wgOut->addWikiText( $msg );
>+		if($wgUser->getRMainPages() != NULL) {
>+ 			# We are going to put some links to restricted namespaces
>+ 			# that the user has access to, so we disable the warning.
>+ 			$wgLinkWarn = false;
>+ 			$wgOut->addWikiText(wfMsg('RNSlist')."<br>".str_replace( '_', ' ',$wgUser->getRMainPages()));
>+ 			$wgOut->returnToMain(false);
>+		} else {
> 		if ( !empty( $this->mReturnTo ) ) {
> 			$wgOut->returnToMain( $auto, $this->mReturnTo );
> 		} else {
> 			$wgOut->returnToMain( $auto );
> 		}
> 	}
>+	}
> 
> 	/** */
> 	function userNotPrivilegedMessage() {
>diff -iEbdu -r ./includes/SpecialWantedpages.php ./includes/SpecialWantedpages.php
>--- ./includes/SpecialWantedpages.php	2006-10-14 02:06:36.000000000 +0200
>+++ ./includes/SpecialWantedpages.php	2006-12-07 15:30:58.871458100 +0100
>@@ -67,10 +67,15 @@
> 
> 
> 	function formatResult( $skin, $result ) {
>-		global $wgLang;
>+		global $wgLang, $wgUser;
> 
> 		$title = Title::makeTitleSafe( $result->namespace, $result->title );
> 
>+		# Don't show wanted pages in restricted namespaces
>+ 		if( !$wgUser->canAccessNamespace( $title->getNamespace() ) ) {
>+ 			return "";
>+ 		}
>+
> 		if( $this->isCached() ) {
> 			# Check existence; which is stored in the link cache
> 			if( !$title->exists() ) {
>diff -iEbdu -r ./includes/SpecialWhatlinkshere.php ./includes/SpecialWhatlinkshere.php
>--- ./includes/SpecialWhatlinkshere.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/SpecialWhatlinkshere.php	2006-12-07 15:30:54.761925300 +0100
>@@ -73,7 +73,7 @@
> 	 * @private
> 	 */
> 	function showIndirectLinks( $level, $target, $limit, $from = 0, $dir = 'next' ) {
>-		global $wgOut;
>+		global $wgOut, $wgUser;
> 		$fname = 'WhatLinksHerePage::showIndirectLinks';
> 
> 		$dbr =& wfGetDB( DB_READ );
>@@ -199,6 +199,11 @@
> 
> 		$wgOut->addHTML( '<ul>' );
> 		foreach ( $rows as $row ) {
>+			#If the linking page is located in a secured namespace, skip it.
>+ 			if(!$wgUser->canAccessNamespace($row->page_namespace)) {
>+ 				continue;
>+ 			}
>+
> 			$nt = Title::makeTitle( $row->page_namespace, $row->page_title );
> 
> 			if ( $row->page_is_redirect ) {
>diff -iEbdu -r ./includes/Title.php ./includes/Title.php
>--- ./includes/Title.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/Title.php	2006-12-07 17:06:26.249622900 +0100
>@@ -1026,6 +1026,10 @@
> 			wfProfileOut( $fname );
> 			return false;
> 		}
>+		if( !$wgUser->canAccessNamespace( $this->mNamespace )) {
>+ 			wfProfileOut( $fname );
>+ 			return false;
>+ 		}
> 		// XXX: This is the code that prevents unprotecting a page in NS_MEDIAWIKI
> 		// from taking effect -ævar
> 		if( NS_MEDIAWIKI == $this->mNamespace &&
>@@ -1133,7 +1137,7 @@
> 			return $result;
> 		}
> 
>-		if( $wgUser->isAllowed('read') ) {
>+		if( $wgUser->isAllowed('read', $this) ) {
> 			return true;
> 		} else {
> 			global $wgWhitelistRead;
>@@ -1147,18 +1151,19 @@
> 			}
> 
> 			/** some pages are explicitly allowed */
>+			if( is_array( $wgWhitelistRead )) {
> 			$name = $this->getPrefixedText();
>-			if( $wgWhitelistRead && in_array( $name, $wgWhitelistRead ) ) {
>+ 				if( in_array( $name, $wgWhitelistRead ) ) {
> 				return true;
> 			}
>-
> 			# Compatibility with old settings
>-			if( $wgWhitelistRead && $this->getNamespace() == NS_MAIN ) {
>+ 				if( $this->getNamespace() == NS_MAIN ) {
> 				if( in_array( ':' . $name, $wgWhitelistRead ) ) {
> 					return true;
> 				}
> 			}
> 		}
>+		}
> 		return false;
> 	}
> 
>diff -iEbdu -r ./includes/User.php ./includes/User.php
>--- ./includes/User.php	2006-10-14 02:06:32.000000000 +0200
>+++ ./includes/User.php	2006-12-07 15:30:54.011896500 +0100
>@@ -871,6 +871,7 @@
> 			}
> 
> 			$effectiveGroups = array_merge( $implicitGroups, $this->mGroups );
>+
> 			$this->mRights = $this->getGroupPermissions( $effectiveGroups );
> 		}
> 
>@@ -1348,16 +1349,155 @@
> 	 * @param string $action Action to be checked
> 	 * @return boolean True: action is allowed, False: action should not be allowed
> 	 */
>-	function isAllowed($action='') {
>+	function isAllowed($action='', $title=NULL) {
>+		global $wgRestrictedNamespaces, $wgReadOnlyNSes;
> 		if ( $action === '' )
> 			// In the spirit of DWIM
> 			return true;
> 
> 		$this->loadFromDatabase();
>+		if( $title == NULL ) {
>+			global $wgTitle;
>+			$title = $wgTitle;
>+		}
>+		$ns = $title->getNamespace();
>+
>+		// If user wants to read a page, that page is in a read only namespace
>+		// and the user has the 'roread' right, allow him to read it. If it has
>+		// the 'roedit' right allow him to edit it.
>+		if( is_array($wgReadOnlyNSes)) {
>+			if( $action == 'read' && in_array($ns, $wgReadOnlyNSes) &&
>+				in_array('roread', $this->mRights) && !$this->isBlocked() ) {
>+					return true;
>+			}
>+			if( $action == 'edit' && !$title->isProtected() &&
>+				in_array($ns, $wgReadOnlyNSes) && in_array('roedit', $this->mRights) && !$this->isBlocked()) {
>+					return true;
>+			}
>+		}
>+
>+		// Prevent access to restricted namespaces if the user does not have all
>+		// required rights.
>+		if( !$this->canAccessNamespace($ns) ) {
>+			return false;
>+		}
>+
>+		// If we are in user's page, allow him to do everything...
>+		if ( $action == 'edit' && ($ns == NS_USER_TALK || $ns == NS_USER) &&
>+			$title->getText() == $this->getName() && !$this->isBlocked() && !$title->isProtected() ) {
>+				return true;
>+		}
>+
>+		if ( $action == 'protect' && ($ns == NS_USER_TALK || $ns == NS_USER) &&
>+			$title->getText() == $this->getName() && !$this->isBlocked() ){
>+				return true;
>+		}
>+
>+		// If user wants to edit a talk page and has the talk right, allow him to do so...
>+		if( $title->isTalkPage() && $action == 'edit' && in_array('talk', $this->mRights) &&
>+			!$this->isBlocked() && !$title->isProtected() ){
>+				return true;
>+		}
>+
>+		// If user wants to leave a mesage on another's user talk page and that page is unprotected, allow him to do so...
>+		if( $action == 'edit' && $ns == NS_USER_TALK && !$this->isBlocked() && !$title->isProtected() ){
>+			return true;
>+		}
>+
>+		// If user has the sedit right, allow him to edit pages in the restricted namespaces
>+		// he has access.
>+		if( is_array($wgRestrictedNamespaces) && array_key_exists($ns, $wgRestrictedNamespaces)
>+				&& $this->canAccessNamespace($ns) && !$this->isBlocked() ){
>+			if( $action == 'edit' && in_array('sedit', $this->mRights) && !$title->isProtected() ) {
>+				return true;
>+			}
>+
>+			// If user has the sprotect right, allow him to edit pages in the  in the restricted namespaces
>+			// he has access.
>+			if(($action == 'protect' || $action == 'unprotect') && in_array('sprotect', $this->mRights)) {
>+				return true;
>+			}
>+
>+			// If user has the sdelete right, allow him to edit pages in the  in the restricted namespaces
>+			// he has access.
>+			if( !$title->isProtected() && ($action == 'delete' || $action == 'undelete') &&
>+				(in_array('sdelete', $this->mRights)) ) {
>+					return true;
>+			}
>+		}
>+
>+		//If the user wants to delete or undelete a page and it's blocked don't allow him to do so.
>+		if( ($action == 'delete' || $action == 'undelete') && ($title->isProtected() || $this->isBlocked()) ){
>+			return false;
>+		}
>+
>+		//If the user wants to protect or unprotect a page and it's blocked don't allow him to do so.
>+		if( ($action == 'protect' || $action == 'unprotect') && $this->isBlocked() ){
>+			return false;
>+		}
>+		
> 		return in_array( $action , $this->mRights );
> 	}
> 
> 	/**
>+	 * Check if user is allowed to access a given namespace
>+	 * @param string $namespace ID of the namespace that needs to be checked.
>+	 * @return boolean True: access is allowed, False: access is denied
>+	 */
>+	function canAccessNamespace( $namespace='' ) {
>+		global $wgRestrictedNamespaces;
>+		$this->loadFromDatabase();
>+		if( is_array( $wgRestrictedNamespaces )) {
>+			if( array_key_exists( $namespace, $wgRestrictedNamespaces ) ) {
>+				if( in_array($wgRestrictedNamespaces[$namespace], $this->mRights)){
>+					return true;
>+				}
>+				return false;
>+			}
>+		}
>+		return true;
>+	}
>+
>+	/**
>+	 * Get the restricted namespaces the user has access to (talk namespaces not included).
>+	 * @return string with the namespace names seperated by the "\n" character/
>+	 */
>+	function getAllowedRNSes() {
>+		global $wgRestrictedNamespaces;
>+		$this->loadFromDatabase();
>+		$names = NULL;
>+		if( is_array( $wgRestrictedNamespaces ) ) {
>+			foreach ($wgRestrictedNamespaces as $nsid => $ugroup) {
>+				#if( $this->canAccessNamespace($nsid) && !($nsid %2) ) { #huh!?!? what the hell is the mod 2 about?
>+				if( $this->canAccessNamespace($nsid) ) {
>+					$names .= Namespace::getCanonicalName($nsid)."\n";
>+				}
>+			}
>+		}
>+		return $names;
>+	}
>+
>+	/**
>+	 * Get the main page title of each restricted namespace (talk namespaces not included)
>+	 * the user has access to.
>+	 * @return string: The titles seperated by the  "\n" character.
>+	 */
>+	function getRMainPages() {
>+		global $wgRestrictedNamespaces;
>+		$titles = NULL;
>+		if( is_array( $wgRestrictedNamespaces ) ) {
>+			$namespaces = $this->getAllowedRNSes();
>+			$nsarray = explode("\n",$namespaces);
>+			foreach ($nsarray as $index => $nsname) {
>+				if($nsname != ""){
>+					$titles .= "[[".$nsname.":".wfMsgForContent( 'mainpage' )."|".$nsname."]]"."<br/>\n";
>+				}
>+			}
>+		}
>+		return $titles;
>+	}
>+
>+	/**
> 	 * Load a skin if it doesn't exist or return it
> 	 * @todo FIXME : need to check the old failback system [AV]
> 	 */
>@@ -1370,7 +1510,8 @@
> 			# get the user skin
> 			$userSkin = $this->getOption( 'skin' );
> 			$userSkin = $wgRequest->getVal('useskin', $userSkin);
>-
>+			ini_set('display_errors', true);
>+			ini_set('error_reporting', 2047);
> 			$this->mSkin =& Skin::newFromKey( $userSkin );
> 			wfProfileOut( $fname );
> 		}
>diff -iEbdu -r ./includes/Wiki.php ./includes/Wiki.php
>--- ./includes/Wiki.php	2006-10-14 02:06:34.000000000 +0200
>+++ ./includes/Wiki.php	2006-12-07 15:30:56.855755700 +0100
>@@ -331,7 +331,6 @@
> 			/* No such action; this will switch to the default case */
> 			$action = 'nosuchaction';
> 		}
>-
> 		switch( $action ) {
> 			case 'view':
> 				$output->setSquidMaxage( $this->getVal( 'SquidMaxage' ) );
>diff -iEbdu -r ./languages/messages/MessagesEn.php ./languages/messages/MessagesEn.php
>--- ./languages/messages/MessagesEn.php	2006-10-14 02:07:00.000000000 +0200
>+++ ./languages/messages/MessagesEn.php	2006-12-07 15:30:59.512107700 +0100
>@@ -1589,6 +1589,7 @@
> # Namespace form on various pages
> 'namespace' => 'Namespace:',
> 'invert' => 'Invert selection',
>+'RNSlist' => 'Available Namespaces',
> 
> # Contributions
> #
>diff -iEbdu -r ./skins/CologneBlue.php ./skins/CologneBlue.php
>--- ./skins/CologneBlue.php	2006-10-14 02:06:12.000000000 +0200
>+++ ./skins/CologneBlue.php	2006-12-07 15:20:32.734904100 +0100
>@@ -183,41 +183,43 @@
> 		$s .= $this->menuHead( "qbfind" );
> 		$s .= $this->searchForm();
> 
>-		$s .= $this->menuHead( "qbbrowse" );
>+		#$s .= $this->menuHead( "qbbrowse" );
> 
>-		# Use the first heading from the Monobook sidebar as the "browse" section
>+		# Use the first two headings from the Monobook sidebar as the "browse" section
> 		$bar = $this->buildSidebar();
>-		$browseLinks = reset( $bar );
>-
>+		foreach($bar as $sectionTitle => $browseLinks)
>+		{
>+			$s .= $this->menuHeadText($sectionTitle);	
> 		foreach ( $browseLinks as $link ) {
> 			if ( $link['text'] != '-' ) {
> 				$s .= "<a href=\"{$link['href']}\">" .
> 					htmlspecialchars( $link['text'] ) . '</a>' . $sep;
> 			}
> 		}
>+		}
> 
> 		if ( $wgOut->isArticle() ) {
>-			$s .= $this->menuHead( "qbedit" );
>-			$s .= "<strong>" . $this->editThisPage() . "</strong>";
>-
>-			$s .= $sep . $this->makeKnownLink( wfMsgForContent( "edithelppage" ), wfMsg( "edithelp" ) );
>-
>-			if( $wgUser->isLoggedIn() ) {
>-				$s .= $sep . $this->moveThisPage();
>-			}
>-			if ( $wgUser->isAllowed('delete') ) {
>-				$dtp = $this->deleteThisPage();
>-				if ( "" != $dtp ) {
>-					$s .= $sep . $dtp;
>-				}
>-			}
>-			if ( $wgUser->isAllowed('protect') ) {
>-				$ptp = $this->protectThisPage();
>-				if ( "" != $ptp ) {
>-					$s .= $sep . $ptp;
>-				}
>-			}
>-			$s .= $sep;
>+#			$s .= $this->menuHead( "qbedit" );
>+#			$s .= "<strong>" . $this->editThisPage() . "</strong>";
>+#
>+#			$s .= $sep . $this->makeKnownLink( wfMsgForContent( "edithelppage" ), wfMsg( "edithelp" ) );
>+#
>+#			if( $wgUser->isLoggedIn() ) {
>+#				$s .= $sep . $this->moveThisPage();
>+#			}
>+#			if ( $wgUser->isAllowed('delete') ) {
>+#				$dtp = $this->deleteThisPage();
>+#				if ( "" != $dtp ) {
>+#					$s .= $sep . $dtp;
>+#				}
>+#			}
>+#			if ( $wgUser->isAllowed('protect') ) {
>+#				$ptp = $this->protectThisPage();
>+#				if ( "" != $ptp ) {
>+#					$s .= $sep . $ptp;
>+#				}
>+#			}
>+#			$s .= $sep;
> 
> 			$s .= $this->menuHead( "qbpageoptions" );
> 			$s .= $this->talkLink()
>@@ -295,6 +297,12 @@
> 		return $s;
> 	}
> 
>+	function menuHeadText( $text )
>+	{
>+		$s = "\n<h6>" . $text . "</h6>";
>+		return $s;
>+	}
>+
> 	function searchForm( $label = "" )
> 	{
> 		global $wgRequest;
Comment 134 Rob Church 2007-01-02 11:40:34 UTC
Please do *NOT* post future patches here, maintain them elsewhere. The above
comment is particularly irritating because it leaves a large, unwanted email in
the inboxes of people who are trying to monitor other, more important bugs.
Comment 135 qsheets095 2007-01-10 01:29:49 UTC
I'm sorry... I meant for it to attach itself to the last attachment since the
edit was so minor (SkinTemplate.php). 
Comment 136 Edward Z. Yang 2007-01-10 01:40:14 UTC
Is there any particular reason why you nuked the CC list?
Comment 137 Kristian Spilhaug 2007-01-19 22:28:20 UTC
I am sorry for disturbing once again, hopefully it will be the last posting here.

Joseph Southwell and myself have made a SourceForge-project of this patch. It
can be found at 

http://sourceforge.net/projects/hiddenwiki/

So far the latest patch only work for MediaWiki 1.8.2, but hopefully it will be
updated soon.

Anyone interested in joining as developers may feel free to send me an e-mail,
and I'll include you as soon as possible.
Comment 138 Rotem Liss 2007-01-20 08:12:10 UTC
*Do not remove people from the CC list.* They will choose whether they would
like to get updates or not. Especially, *do not remove wikibugs-l@wikipedia.org
from the CC list*, as many people use it to get updates from all the bugs.
Comment 139 Rotem Liss 2007-01-20 08:14:09 UTC
Changed Assigned field, sorry for the bug-spam.
Comment 140 JayEdgar 2007-02-02 15:57:50 UTC
Will this mod be updated for MW 1.9? or does the status=closed(wontfix) mean that it's done?

Many thanks.
Comment 141 Kristian Spilhaug 2007-02-02 16:10:52 UTC
As mentioned in comment #137:

Check out http://sourceforge.net/projects/hiddenwiki/ for updates and new
releases for this patch, or if you want to contribute with the development.

Please post comments and requests there, and NOT here.
Comment 142 JayEdgar 2007-02-02 16:22:30 UTC
My apologies. I didn't see 137. /jte

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


Navigation
Links