[pmwiki-users] field admin permissions oddness

[marc]

Patrick R. Michaud said...
> On Mon, Oct 02, 2006 at 04:42:40PM +0100, marc wrote:
> > Patrick R. Michaud said...
> > > Similarly, if there are two wikis on a farm that share the same
> > > FQDN, then PHP will treat them as sharing a common session.
> > 
> > Check.
> > 
> > > This
> > > is why the session_name() approach mentioned in my previous email
> > > works -- it tells the browser to use a different session cookie
> > > for each wiki instance, even though they're on the same FQDN.
> > 
> > Okay, but what I would like is a single user log-on for the farm - all 
> > fields in the farm - but for permissions to be field-specific. Thus, if 
> > fred is admin for field one, but not field2, when he logs in he is not 
> > given admin perms for field2, as happens currently. Is there a way to do 
> > this?
> 
> Hmm, this is a bit trickier -- I'll have to think about it.

Well, you have nothing else on... ;-)
 
> > Isn't there a potential problem here? (Not that it can't be managed.) 
> > For example, if non-admin dino logs in to field1 and is a member of 
> > group @testers for field1, then he also a member of @testers for all 
> > other fields. IOW, authorization groups are farm-wide (when not using 
> > multiple session_names).
> 
> Please don't phrase it this way...it's very misleading because
> authenticated groups are not really "farm-wide".

Argh! For the second time today. Sorry. I was trying to think of an 
example to demonstrate my concern, and I wanted to keep it terse - hence 
the use of the horrible term, farm-wide.
 
> The real truth is that authentication groups are shared among
> wikis that have the same FQDN and session_name.  The wikis
> don't even to be part of the same farm -- if the FQDN and session_name
> match for a pair of wikis, they end up sharing authentication groups.

> That's just the nature of the way PHP sessions work and the way
> PmWiki uses sessions to manage authentication credentials.
> (PmWiki stores group authentications in a session so that it
> doesn't have to re-compute group memberships from Site.AuthUser
> on every page request, which could get expensive.)
> 
> So, what you're really asking is that a person's authenticated
> identities be able to travel across wikis, but not any group 
> memberships.  I'm not sure we want to do this in general, as
> it would surprise people that the identities defined in 
> Site.AuthUser can travel across wikis, but the groups do not.

That's the management I mentioned earlier. I think that as long as 
there's a local policy to keep groups with permissions unique to a 
field, then issues shouldn't arise.

> Also, PmWiki is slowly moving towards blurring the distinction 
> between "identity" and "group"; e.g., allowing things such as an
> authentication group that says "Alice, Bob, and all of the members
> of @editors".  In fact, the only thing that really distinguishes 
> an identity from a group now is the "id:" versus the "@" prefix
> in authorizations -- other than that they're handled identically.
> 
> My (weak) suggestion at this point would be to keep identities
> separate among wikis.  This will require that people have to
> re-authenticate when crossing a wiki boundary, but for most
> sites that shouldn't be too much of an annoyance.  If that's
> really a serious obstacle for you, we can discuss it more here.

Yes, it's a serious obstacle, but I think that I can manage the groups.

-- 
Best,
Marc