[pmwiki-users] Default group with authentication

Tegan Dowling tmdowling at gmail.com
Wed Feb 28 21:33:22 CST 2007


On 2/28/07, Kathryn Andersen <kat_lists at katspace.homelinux.org> wrote:
> On Wed, Feb 28, 2007 at 11:58:51PM +0000, Keith Edmunds wrote:
> > I'm new to pmwiki, so apologies if this is a naive question.
> >
> > I'm considering using pmwiki as a CMS, and have read the recipes about
> > doing so. One feature I want is for there to be a consistent menu for
> > all authenticated users, but for the actual page linked to for each
> > menu item to be unique per group of users. For example, there might be
> > a 'my page' link for all authenticated users, but the page displayed
> > will depend on which user is logged in.
> >
> > I think I can do that with groups, and I also think that I can prevent
> > users in group X seeing the 'my page' page for group Y - is that
> > correct?
> >
> > My real question, however, is can I set up a default group for each
> > user, so that when I display the menu, I can say "this is user Smith,
> > who has a default group is X, therefore the destination for the
> > menu item 'my page' is X/mypage"? Or maybe at authentication I should
> > make the default group (for user Smith) be X - is that straightforward
> > to do (and sensible)?
>
> Okay, there are a few requirements here, so far as I understand:
> (a) each user has their own private group (or is it just sufficient that
> each user have their own private page?)
> (b) the normal menu should contain a link to MyGroup/MyPage
> (c) Smith cannot see (read) anything in the group which belongs to Jones
>
> Okay.  All of the above will need user-based authentication (rather than
> password-based), especially part (c).  I suggest AuthUser because it's
> in the core, and is better-supported.
> So, say, Smith would have a login id of 'smith', and Jones would have a
> login id of 'jones'.
>
> To solve (a) and (b), I think the easiest thing would be to have a
> page-variable which creates a group-name based on the $AuthId (login id)
> of the user.
>
> $FmtPv['$MyGroup'] = ... (some function to convert $AuthId into a group
> name -- sorry, I don't have time to write one right now)
>
> Then you could put, in your menu:
>
> *[[{$MyGroup}/MyPage]]
>
> Then for Smith, it would point to Smith's group (whatever it was;
> perhaps the simplest version would be converting "smith" to "Smith") and
> for Jones, it would be Jones, and so on.  Depending on the function you
> write, perhaps you would call them SmithGroup and JonesGroup --
> whatever.
>
> To prevent Smith from reading JonesGroup, you would then create
> JonesGroup.GroupAttributes, and set the "read" permission to
>
>         id:jones
>
> Then only Jones could read JonesGroup.
>
> Or, if you wanted to make it so that only Jones could *edit* pages in
> JonesGroup, you would set the edit permission (rather than the read
> permission).

There is something really close to this that you can do without the
AuthUser or any other user-authentication scheme - i.e., just using
the native password authentication.

On a couple if my sites, I provide each user with a wikigroup of
his/her own, which wikigroup is only visible to someone who knows (one
of) its read-password(s).  I use a pagelist on a login page, which
lists all the wikigroups on the site (minus a select, manually
excluded few), but takes advantage of the default rule for pagelists
which rules that pagelist results will only display links to
pages/groups for which the user has read-rights.

Email me off-list if you'd like a demo.

What you asked for that this method won't provide is having the user's
wikigroup automatically have the same name as the user.  You can still
do this manually, of course, but since under the native
password-authentication scheme, user-name doesn't get authenticated,
so you can't (far as I know) automate the relationship.  You just
create the user's group, set its password(s) and provide it/them to
the user.

Just so you know of this option.  Happy to provide details if you want them.

Tegan



More information about the pmwiki-users mailing list