[Pmwiki-users] Nested group permissions

[Patrick R. Michaud]

Also, just for clarification, currently PmWiki treats each group
as being in a separate HTTP realm for authentication purposes.  Thus, 
even if the user supplies a password for the NC17 group (realm), when he
goes to the PG13 group it will still prompt once for a password.  However,
in the PG13 group the NC17 and XXX passwors should work as well as the
PG13 ones.

I can make a modification to pmwiki.php to allow the site administrator
to decide what realm (if any) to issue with the authentication
requests...

Also, can you add $EnableDiag = 1 to your local.php, and then
send me the output resulting from adding "?action=diag" to one of
your PG13 urls (or send me a URL to use so that I can look it up
directly).  You probably don't want to post the output of ?action=diag
to the listserv.

Pm


On Wed, 30 Apr 2003, Crisses wrote:

> > That's it!  Let me know if you need any clarification on anything.
> 
> Ok:  it does not work right now:
> 
> For example: tried entering the NC17 edit password to read NC17, it asked
> for a password.  Put in NC17 edit password to edit an NC17 page, it worked,
> but I could not edit PG13, could not read NC17 (both asked for a password).
> I entered the read PG13 password to read PG13, it worked.  Checked GRating
> read access and this worked (this puzzled me, given everything else, maybe I
> erred in encrypting a password?, so I'll check that). Then I tried XXX read
> password to read XXX, it worked, then I tried to view a NC17 page, it asked
> for a password.  I went back to try to read Grating, which just worked, and
> it asked for a password, so it forgot that I just had access.
> 
> So something's not quite right.  Edit passwords are not granting read
> access, or lower-level edit access.  Read passwords at upper levels are not
> granting read access at lower levels (with the strange possible exception of
> PG13 read having granted GRating read?).  I tested several times by
> reloading a browser and using another browser (just so it would reset my
> passwords), and had the same problems.  I went through and 'cleared' the
> group passwords from the webbrowser using the admin password, also, in case
> that was interfering.
> 
> 
> 
> 
> This is what I put in the local.php file:
> 
> $DefaultPasswords['attr'] = '*'; # negates per-page passwords
> 
> 
> ## The following code is added by Crisses to create nested pswds
> ## Code supplied by PMichaud
> 
>     $grouplevels = array('GRating'=>1, 'PG13'=>2, 'NC17'=>3, 'XXX'=>4);
>     $pwread['GRating'] = ('encryptedpassword');
>     $pwedit['GRating'] = ('encryptedpassword');
>     $pwread['PG13'] = ('encryptedpassword');
>     $pwedit['PG13'] = ('encryptedpassword');
>     $pwread['NC17'] = ('encryptedpassword');
>     $pwedit['NC17'] = ('encryptedpassword');
>     $pwread['XXX'] = ('encryptedpassword');
>     $pwedit['XXX'] = ('encryptedpassword');
> 
> ## Note that each of the $pw entries can be arrays if you want to
> ## distribute some multiple passwords.  Then, figure out what group
> ## we're in, and get the level for the current group:
> 
>     $group = FmtPageName('$Group',$pagename);
>     $thislevel = $grouplevels[$group];
> 
> 
> ## Set up the $DefaultPasswords entries depending on
> ## the current group.  Basically, passwords in groups with equal or
> ## higher levels than the current one are added to the arrays:
> 
>     foreach ($grouplevels as $g=>$v) {
>       if ($v>=$thislevel) {
>         $DefaultPasswords['read'] =
>           array_merge($DefaultPasswords['read'],$pwread[$g]);
>         $DefaultPasswords['edit'] =
>           array_merge($DefaultPasswords['edit'],$pwedit[$g]);
>       }
>     }
> 
> ## allow all of the edit passwords to be accepted for read
> ## actions:
> 
>     $DefaultPasswords['read'] =
>       array_merge($DefaultPasswords['read'],$DefaultPasswords['edit']);
> 
> 
> Thanks so much :)
> 
> Crisses
>