• View
• Edit
• History
• Attach
• Print

01257: $EnablePageListProtect=1 ignored when search performed from page with read access

Description: With $EnablePageListProtect = 1 or default, pages from restricted group "Conspiracy" show up in search results if a search field is used on a page of a group "Nothingtohide" where the user has already succesfully logged in. They do not show up (as expected) if the same user is using the search field on a blocked page of group "Conspiracy" itself.

The passwords are set in config.php only with something like:

$group = PageVar($pagename, '$Group');
if ($group == "Nothingtohide") {
 $DefaultPasswords['edit'] = array(crypt('boss'));
 $DefaultPasswords['read'] = array(crypt('boss'));
 $DefaultPasswords['upload'] = array(crypt('boss'));
}
if ($group == "Conspiracy") {
 $DefaultPasswords['edit'] = array(crypt('sneaky'));
 $DefaultPasswords['read'] = array(crypt('sneaky'));
 $DefaultPasswords['upload'] = array(crypt('sneaky'));
}

Now boss will discover Conspiracy while searching within Nothingtohide (even if he could not actually read the pages, but the page names could be telling enough).

Hello. This method of setting group or page passwords is wrong -- not only people can see the remote pages, but they can also include content from them. To set group passwords, go to [[YourGroup.GroupAttributes?action=attr]] and set the passwords there. To set page passwords, go to [[YourGroup.YourPage?action=attr]] and set the passwords there. See PmWiki:Passwords. --Petko June 27, 2011, at 01:43 PM

Thank you, Petko. So this is not a bug. But with GroupAttributes?action=attr, I have to set all the passwords by hand, while I was hoping to be able to set them by script to have them all in one place, config.php, and not to lose track of them... Frank June 28, 2011, at 11:00 AM

Setting them in GroupAttributes is the only secure way. The page SiteAdmin.AuthList on your wiki is a list of all protected pages and groups. --Petko June 29, 2011, at 06:19 AM