[pmwiki-users] field admin permissions oddness
gmane at auxbuss.com
Mon Oct 2 12:20:45 CDT 2006
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.
More information about the pmwiki-users