[pmwiki-users] General Farming Questions

[Sivakatirswami]

OK, Patrick I'm digging into this advice and playing with it.

This all makes good sense, but the only hitch is the requirement to  
set the

id: for every group. A global solution would be better...

Let me feed this back to you so you can see if I got it right...

  I will use "SuperUser" for someone who is allowed to read, write  
and create all pages and groups.

OK the main site, that should be accessible by SuperUser, has right  
now about 32 groups... and growing (1 group for each web dev  
project...) Let say for a subset of users we only want them to see  
group 32 which we call "ChapatiRecipes"

If I use the server's GUI htaccess tools and set the up the following  
users:

SuperUser (already exists.. the following would be new:)
Alice
Rajan
Yogi

for the whole site, then it means I need to go in and set the read  
and write attribute for 31 groups to

id:SuperUser

then for  "ChapatiRecipes" we set auth to read and write to

id:Alice,Rajan,Yogi

OK, so now, when Alice logs in, she gets the Apache authentication  
request... and she lands in ChapatiRecipes

(Of course I would have to give her the URL for her group... after  
setting up "clean" urls of course like http://www.someDomain/wiki/ 
ChapatiRecipes/, I found the cookbook for that one...)

So now.. I guess if a SuperUser comes in and creates a new group, and  
I am not aware of it, then suddenly we have an "open" group.. that  
even Alice,Rajan, Yogi could see... Of course Alice, Rajan and Yogi  
are very unlike to know about it unless someone gave them the URL and  
since there will be no navigation in ChapatiRecipes outside of  
ChapatiRecipes, we have a kind of "blind eye" security... but not  
"real" security.

point: this recipe requires that the ID:SuperUser be set for ever new  
group that is created.

Actually that's not such an onerous burden, except in theory...  I  
mean, you do it once for existing groups and then new groups created,  
which are not that often.. not a big deal... but, just wondering if  
there were a more global option to

1) restrict access to groups 1-31 (and any new created ones) to  
SuperUser
2) access to group 32 to Alice,Rajan, Yogi..

In xTalk I would write this like this (a general algorithm.. I don't  
know PHP, I do everything with Revolution...)

repeat for each line x in theListOfAllGroups
   if the ID for group x is empty then
         set the ID of group x to "SuperUser"
   end if
end repeat

i.e. if a group has no ID setting, then it defaults to a particular  
authorization setting that is stored somewhere.... presumably in the  
local/config.php for the whole wiki a kind of dynamic sitewide auth  
setting on startup.

Then, if a particular group has and explicit readAttribute set to

id:Alice,Rajan,Yogi

the latter over rides the sitewide auth setting

Sivakatirswami










On Sep 28, 2005, at 4:47 PM, Patrick R. Michaud wrote:

> Well, you're already setting up .htaccess files, so I'd continue to
> use that.  However, instead of having separate .htaccess files for
> each wiki field, I'd set up a single .htaccess file that protects
> the entire wiki (all groups).
>
> In the local/config.php, add the line:
>
>     if (@$_SERVER['REMOTE_USER']) $AuthId = $_SERVER['REMOTE_USER'];
>
> This tells PmWiki to honor any authentication performed by the
> webserver, and we continue to allow Apache to perform the  
> authentication
> (and you continue to use your web admin GUI and maintain passwords
> there).
>
> Then, to limit access to a group XYZ to users alice, bob, and carol,
> simply set the read password of XYZ.GroupAttributes to
>
>     id:alice,bob,carol
>
> Anyone who isn't logged in as alice, bob, or carol won't be able
> to read the pages in that group.