Extension talk:Hidden pages
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
editWe (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
editProposal 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
edit[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 m:Extended template syntax and m:Extended template syntax/Alternative conditional syntax proposal
--- Check out includes/Parser.php...
--Def 23:13, 23 Jun 2005 (UTC)
Combinations of user rights
editAs 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?
editI 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
editHi 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
edit$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)
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.
Custom namespaces
editHi, 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
editWhen 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)
Patches to fix Bugs I've had
editSorry if this is the wrong place to put this, not sure where the right one is --SiBaz 23:35, 02 March 2012 (UTC)
Strange Bug, wipes other UserPermissions
editdiff -ur html.wiki/includes/User.php mediawiki-upgrades/mediawiki-1.16.5.patch/includes/User.php
--- html.wiki/includes/User.php 2012-03-02 23:25:08.000000000 +0000
+++ mediawiki-upgrades/mediawiki-1.16.5.patch/includes/User.php 2012-03-02 20:34:12.000000000 +0000
@@ -2251,8 +2251,6 @@
if( !$wgUseRCPatrol && !$wgUseNPPatrol )
return false;
}
- $this->getRights();
-
$this->loadFromDatabase();
if( $title == NULL ) {
global $wgTitle;
Removed extra blank option in Skin sideBar
edit--- html.wiki/includes/Skin.php 2012-03-02 22:59:37.000000000 +0000
+++ mediawiki-upgrades/mediawiki-1.16.5.patch/includes/Skin.php 2012-03-02 20:34:12.000000000 +0000
@@ -2086,7 +2086,7 @@
wfRunHooks( 'SkinBuildSidebar', array( $this, &$bar ) );
$heading = 'hidden pages';
- $lines = explode( "\n", trim($wgUser->getAllowedRNSes()) );
+ $lines = explode( "\n", $wgUser->getAllowedRNSes() );
if (count($lines) > 0 && $lines[0] != '') {
foreach ($lines as $line) {
$bar[$heading][] = array(
Added Language entries
editdiff -ur html.wiki/languages/messages/MessagesEn.php mediawiki-upgrades/mediawiki-1.16.5.patch/languages/messages/MessagesEn.php
--- html.wiki/languages/messages/MessagesEn.php 2012-03-02 22:54:39.000000000 +0000
+++ mediawiki-upgrades/mediawiki-1.16.5.patch/languages/messages/MessagesEn.php 2011-04-28 16:08:38.000000000 +0100
@@ -4217,6 +4217,4 @@
'htmlform-reset' => 'Undo changes',
'htmlform-selectorother-other' => 'Other',
-'noaccesstitle' => 'Access Denied',
-'noaccesstext' => 'You do not have permission to Access this page',
);
diff -ur html.wiki/maintenance/language/messages.inc mediawiki-upgrades/mediawiki-1.16.5.patch/maintenance/language/messages.inc
--- html.wiki/maintenance/language/messages.inc 2012-03-02 22:57:43.000000000 +0000
+++ mediawiki-upgrades/mediawiki-1.16.5.patch/maintenance/language/messages.inc 2011-04-12 13:41:59.000000000 +0100
@@ -392,8 +392,6 @@
'customcssjsprotected',
'ns-specialprotected',
'titleprotected',
- 'noaccesstitle',
- 'noaccesstext',
),
'virus' => array(
'virus-badscanner',
- The patch itself is hosted and maintained at SourceForge. Thanks, I'll see if I can add the fixes to upcoming patches.
- --KristianS (talk) 18:37, 25 July 2012 (UTC)
Support for 1.18?
editI was trying to apply the patch to a 1.18.2 installation, and dumb as a door knob as I am, I didn't do a --dry-run first... Well it messed up my wiki pretty bad :-(
Coming here I seem to understand what went wrong, as there has only been a single post in the last year. Has this project been abandoned? or do plans for 1.18 support exist?
As I had documented every change I'd made, for my colleagues, starting over was not that big a deal. This time I did a --dry-run on my clean new 1.18.3 installation. I've included the output of that attempt. If somebody more versed in version control, can take a look and tell me what to do to get this to work, I'd be grateful. --Troels (talk) 11:10, 27 April 2012 (UTC)
troels@UR2012-0005-VM:/var/www$ sudo patch -p1 --dry-run < hidden-1.16.1.patch patching file includes/CategoryPage.php Hunk #1 succeeded at 323 with fuzz 2 (offset 97 lines). Hunk #2 FAILED at 265. 1 out of 2 hunks FAILED -- saving rejects to file includes/CategoryPage.php.rej patching file includes/DefaultSettings.php Hunk #1 succeeded at 872 with fuzz 1 (offset -2136 lines). patching file includes/Export.php Hunk #1 FAILED at 301. 1 out of 1 hunk FAILED -- saving rejects to file includes/Export.php.rej patching file includes/ImagePage.php Hunk #1 FAILED at 651. 1 out of 1 hunk FAILED -- saving rejects to file includes/ImagePage.php.rej patching file includes/OutputPage.php Hunk #1 FAILED at 1795. Hunk #2 FAILED at 1833. 2 out of 2 hunks FAILED -- saving rejects to file includes/OutputPage.php.rej patching file includes/QueryPage.php Hunk #1 FAILED at 181. 1 out of 1 hunk FAILED -- saving rejects to file includes/QueryPage.php.rej patching file includes/Skin.php Hunk #1 FAILED at 2068. Hunk #2 succeeded at 1210 (offset -875 lines). 1 out of 2 hunks FAILED -- saving rejects to file includes/Skin.php.rej patching file includes/SkinTemplate.php Hunk #1 succeeded at 1382 (offset 270 lines). patching file includes/Title.php Hunk #1 FAILED at 1056. Hunk #2 FAILED at 1554. 2 out of 2 hunks FAILED -- saving rejects to file includes/Title.php.rej patching file includes/User.php Hunk #1 succeeded at 1031 (offset 71 lines). Hunk #2 FAILED at 2227. Hunk #3 succeeded at 2502 with fuzz 2 (offset 266 lines). 1 out of 3 hunks FAILED -- saving rejects to file includes/User.php.rej patching file includes/parser/Parser.php Hunk #1 succeeded at 1747 (offset 75 lines). Hunk #2 succeeded at 2938 (offset 144 lines). Hunk #3 FAILED at 2982. Hunk #4 FAILED at 2991. 2 out of 4 hunks FAILED -- saving rejects to file includes/parser/Parser.php.rej patching file includes/search/SearchEngine.php Hunk #1 FAILED at 253. 1 out of 1 hunk FAILED -- saving rejects to file includes/search/SearchEngine.php.rej patching file includes/specials/SpecialAllpages.php Hunk #1 FAILED at 36. Hunk #2 FAILED at 48. 2 out of 2 hunks FAILED -- saving rejects to file includes/specials/SpecialAllpages.php.rej patching file includes/specials/SpecialBrokenRedirects.php Hunk #1 succeeded at 80 with fuzz 1 (offset 32 lines). patching file includes/specials/SpecialListredirects.php Hunk #1 FAILED at 28. Hunk #2 FAILED at 43. 2 out of 2 hunks FAILED -- saving rejects to file includes/specials/SpecialListredirects.php.rej patching file includes/specials/SpecialMostlinked.php Hunk #1 succeeded at 93 (offset 6 lines). patching file includes/specials/SpecialNewpages.php Hunk #1 FAILED at 244. 1 out of 1 hunk FAILED -- saving rejects to file includes/specials/SpecialNewpages.php.rej patching file includes/specials/SpecialPrefixindex.php Hunk #1 succeeded at 38 (offset 22 lines). Hunk #2 FAILED at 27. 1 out of 2 hunks FAILED -- saving rejects to file includes/specials/SpecialPrefixindex.php.rej patching file includes/specials/SpecialRecentchanges.php Hunk #1 FAILED at 269. 1 out of 1 hunk FAILED -- saving rejects to file includes/specials/SpecialRecentchanges.php.rej patching file includes/specials/SpecialUserlogin.php Hunk #1 succeeded at 816 (offset -4 lines). Hunk #2 succeeded at 824 (offset -4 lines). patching file includes/specials/SpecialWhatlinkshere.php Hunk #1 FAILED at 78. Hunk #2 succeeded at 246 with fuzz 2 (offset 20 lines). 1 out of 2 hunks FAILED -- saving rejects to file includes/specials/SpecialWhatlinkshere.php.rej troels@UR2012-0005-VM:/var/www$
- There's no support for 1.18 so far. I find that I have less time to fiddle with this patch than I would like, but I hope that I'll have time to update it again in the forseeable future. Check out the SourceForge project site if you want notification on updates.
- --KristianS (talk) 18:38, 25 July 2012 (UTC)