<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Tegan,<br>
<br>
That worked for the group. <br>
<br>
I'm a little surprised by this though:<br>
<br>
1. Last time I checked, to edit a page you need to be able to read it
(ie read permission is implied), therefore conferring edit rights
should most certainly confer read rights.<br>
<br>
2. Requiring explicit matching of passwords where site-wide rights
should be conferred to groups, obstructs the intention by creating
unnecessary administrative work (should the site-wide password have to
change). Seems to me letting groups and pages inherit rights through
@_site_edit (ie @_site_<whatever-right>), and also letting pages
inherit group rights with @_group_edit, would make sense, and be
natural and symmetrical. The current situation, given the potential
time and errors involved in changing a password scheme is, ironically,
a security risk.<br>
<br>
3. The apparent application of the publish password to the attribute
password in the group is just plain nuts (ie a bug.).<br>
<br>
Looks to me like this password system could use a bit of attention.<br>
<br>
How does all this compare with generally accepted permission scheme
standards? Am I missing something?<br>
<br>
- Henrik<br>
<br>
Tegan Dowling wrote:
<blockquote
cite="mid:5c8455a0805121953v273b25f7ycaaa44cc9cc55058@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, May 12, 2008 at 5:12 PM, Henrik Bechmann <a class="moz-txt-link-rfc2396E" href="mailto:henrik@bechmann.ca"><henrik@bechmann.ca></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">When I login with a site-wide edit password, I am challenged for an
additional *read* password for a group for which I have set a read password.
I'm having a little trouble fathoming this. I thought that an edit
password trumps a read password.
</pre>
</blockquote>
<pre wrap=""><!---->
It doesn't. Read and edit permissions are set separately, and edit
rights do not confer read rights, any more than read rights confer
edit rights.
If, in your config.php file, you have
$DefaultPasswords['edit'] = crypt('userpasswordhere');
Then in any wikigroup named, for example, ProtectedGroup, you need to
use ProtectedGroup.GroupAttributes?action=attr to:
Set new read password = userpasswordhere
OR use ProtectedGroup.GroupAttributes?action=attr to:
Set new read password = specialgrouppass userpasswordhere
Set new edit password = specialgrouppass userpasswordhere
(create a space-separated list of passwords for each attribute)
You cannot use ProtectedGroup.GroupAttributes?action=attr to:
Set new read password = @_site_edit
That doesn't work. In discussion in this list-serv in 2006, PM said
that he never intended @_site_edit to be used on
GroupAttributes?action=attr.
(Everybody please VOTE on <a class="moz-txt-link-freetext" href="http://www.pmwiki.org/wiki/PITS/00836">http://www.pmwiki.org/wiki/PITS/00836</a>).</pre>
<pre wrap="">
<hr size="4" width="90%">
No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.16/1429 - Release Date: 5/12/2008 6:14 PM
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Henrik Bechmann
bechmann.ca
Webmaster, celos.ca webhosting services</pre>
</body>
</html>