Extension talk:Hidden pages

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Request to extend documentation

We (users not developers of media wiki) are having some trouble to understand the documentation for 1.5

Current documentation:

$wgExtraNamespaces = array(100 => "Sysopspace", 101 => "Sysopspace_Talk");

$wgRestrictedNamespaces = array(100 => "namespaceGrp1", 101 => "namespaceGrp2");

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

$wgGroupPermissions['win_users']['namespaceGrp1'] = true;

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

$wgGroupPermissions['win_users']['namespaceGrp2'] = true;

Questions

• We guess that win_users is a group of users. Right?

Right

• Is namespaceGrp1 a group of namespaces? So is this valid?

$wgRestrictedNamespaces = array(100 => "nGrp1", 101 => "nGrp1", 110 => "nGrp2");

No namespaceGrp1 is a right. Using $wgRestrictedNamespaces you asign a namespace id to a right (priviledge), you then asign the same right to each usergroup you want to have access to the namespace...

e.g.

$wgExtraNamespaces = array(100 => "Sysopspace", 101 => "Sysopspace_Talk");

$wgRestrictedNamespaces = array(100 => "sys_space", 101 => "sys_space");

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

$wgGroupPermissions['the_boss']['sys_space'] = true;

• May a (restricted) namespace group have the same title/name as a (custom) namespace?

$wgExtraNamespaces = array(100 => "nGrp1", ...);

$wgRestrictedNamespaces = array(100 => "nGrp1", ...);

Yup ! the thing works with namespace ids not namespace names ;-)

• Agreed, I've tried every conceivable combination of configuration to make a particular namespace accessible to only a particular user group, and have got nowwhere. Tried all the examples in the "documentation" and in bug 1924 and no joy whatsoever. All I've managed to do is make a namespace that noone can access. Jberanek

md5

Proposal 1:

User adds his/her MD5 password checksum (or several checksum(s)) or public keys in the form of a token

__UNHIDE_FOR_07549e0b7c0086127c19ed5acf079ae5__   = MD5(wiki_account_password(User X))
__UNHIDE_FOR_5edf5c5751e073c14699db8b6b939052__   = MD5(wiki_account_password(User Y)) 

(see http://pajhome.org.uk/crypt/md5/ and en:MD5)

to the page he or she wants to make hidden.

From the moment on that such a MD5 is stored on the page, the wiki renders this page only for the(se) user(s) having a fitting crypted password or key (the wiki knows the user visiting that page and can compare stored password and MD5.

• implementation is quite easy, adminstration of closed users groups possible
• negative aspect: the page name (title) is not hidden, only the content.
• cracking would be theoretically possible if only MD5 is used

--Nyxos 21:17, 5 Sep 2004 (UTC)

I do not understand why a key has to be stored at the pages. Something like

__UNHIDE_FOR_User_X__

Should do the same, don't it? Personally I prefer hiding a whole namespace because in this way it is not possible do hide any page - you have to decide of you want a page to be hidden before creating it.

--- Keys like _NOTOC_ are proccessed during parsing, and change the way the page is displayed for everybody, it's not a 'per user' proccess...

For what you say, new database fields should be created.

Hidden templates are also desirable

[First, excuse me if I'm re-hashing an old discussion; I'm fairly new to mediawiki, but eager to get the most out of it. --Def]

It has been said that pages in the hidden namespaces cannot be used as templates due to page caching. This appears to be accurate, but there are some useful (good?) things that can happen if so-called "hidden templates" can be made to work. The biggest benefit (Warning: POV) is that the contents of a given article can be made to change depending upon the rights of the user viewing it. Consider the following example.

An article containing details of a network design is written. Among the details are items of varying sensitivity. These may be passwords or anything else that the general population using the wiki don't need to see. Rather than placing these into the main article, these are placed in the {{restrict-1:network/pass1}} - {{restrict-1:network/passN}} articles. Now, in the main article (titled simply "network" in this scenario), we transclude the templates into the right place, all nice and neat. Viewers who have rights see the passwords or other info, while others see nothing. It might be nice to have some "not authorized" text in the latter case, but it is not necessary.

See also Extended template syntax and Extended template syntax/Alternative conditional syntax proposal

--- Check out includes/Parser.php...

--Def 23:13, 23 Jun 2005 (UTC)

Combinations of user rights

As I have indicated on this page, it is possible to list multiple user rights required for access to a hidden namespace. In the example:

$wgRestrictedNamespaces = array(100 => array ("sysop","win_users"), 101 => array ("sysop","win_users"));

both ns:100 and ns:101 are restricted to the sysop AND win_users rights. In other words,

• sysops who are not win_users cannot access these namespaces
• win_users who are not sysops cannot access these namespaces
• only sysops who are also win_users can access these namespaces

This is handy, of course, but it would also be nice to have an "or" relationship for user rights. This way, we could specify "sysops OR foo" for the FooNamespace, and "sysops OR bar" for the BarNamespace, easily allowing sysops access to both without having to add both the foo and bar rights to all sysops.

This is not call to remove the current functionality. "AND" relationships are very useful as well. I simply believe that "OR" (and perhaps even "XOR") relationships should be available. The question is, what semantics in the $wgRestrictedNamespaces array would support this?

--Def 03:48, 24 Jun 2005 (UTC)

Built-in support for hidden pages in 1.5?

I am hearing that 1.5 will not have support for hidden or restricted access. Is this the case? LarryEitel 22:23, 24 Jun 2005 (UTC)

I don't think the trunk version of mediawiki will ever have this feature in standard. As explained, this functionnality is not the base of a wiki, so it's not to be included in the main dist. However, as it can be useful to people, this feature is maintained as a patch for mediawiki. --Batmat 15:30, 21 January 2006 (UTC)

including restricted links

Hi all! I'm trying to include a link to a restricted page on the navigation box, only visible for those whom can read the page. But I can't. I have patched mediawiki 1.4.5 with bugzilla:1924 and I'm trying this on LocalSettings.php, right after the $wgNavigationLinks array:

/*  TopSecret is the restricted namespace. Both 'topsecretindex' and 'topsecretindex-url'
    are defined in languages/Language.php.
*/
if ($wgUser->canAccessNamespace(array_search('TopSecret', $wgRestrictedNamespaces)))
{
    $wgNavigationLinks[] = array( 'text'=>'topsecretindex', 'href'=>'topsecretindex-url');
}

But I only got this error:

Fatal error: Call to a member function on a non-object in /home/johndoe/public_html/mediawiki/LocalSettings.php on line 69

It's possible to do what I need, in a different valid way? Thanks. Kiusap 08:51, 29 September 2005 (UTC)

Missing

$wgRestrictedNamespaces = array(100 => "sys_space", 101 => "sys_space");

Where is information about this function ? I found nothing. fr:user:yug 19:31, 11 March 2007 (UTC)

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

Custom namespaces

Hi, there will be a clash with the namespaces in case one uses this extension together with Semantic MediaWiki. I think it would be advisable to change this (changing the instructions) and register the namespaces used by this extension. Cheers --[[kgh]] 17:39, 30 January 2011 (UTC)

---

I see. The conflict is based on the namespace numbering. Semantic MediaWiki uses the namespaces from 100 and up. I'll see what I can do. Thanks for the tip.

--KristianS 23:03, 3 February 2011 (UTC)

Cheerfully done. :) This will not be a problem for experienced administrators, but changing this would make it more "bullet proof" --[[kgh]] 13:06, 4 February 2011 (UTC)

Update for 1.17

When is the update for MediaWiki 1.17 going to be released?

--Fulv 04:50, 28 July 2011 (UTC)

---

I don't have a date for it, but I'm planning to look into it fairly soon. Hopefully within a couple of months.

--KristianS 10:49, 15 August 2011 (UTC)