[pmwiki-users] General Farming Questions
katir at hindu.org
Wed Oct 5 01:20:13 CDT 2005
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
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
SuperUser (already exists.. the following would be new:)
for the whole site, then it means I need to go in and set the read
and write attribute for 31 groups to
then for "ChapatiRecipes" we set auth to read and write to
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
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
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"
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
the latter over rides the sitewide auth setting
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
> (and you continue to use your web admin GUI and maintain passwords
> Then, to limit access to a group XYZ to users alice, bob, and carol,
> simply set the read password of XYZ.GroupAttributes to
> Anyone who isn't logged in as alice, bob, or carol won't be able
> to read the pages in that group.
More information about the pmwiki-users