On Tuesday 20 November 2001 18:15, Ian Bicking wrote:
> On Tue, 2001-11-20 at 19:10, Tavis Rudd wrote:
> > > Another issue with roles/groups: how to contextualize them. In
> > > Zope you have Aquisition and the ACL folders, so that you can
> > > give permissions to a section of the path to a user. In my own
> > > programming, I've found situations when you want to say "this
> > > person is a X with respect to class Y", like "this person is an
> > > editor of book X". This doesn't fit into normal ACLs, except
> > > by way of a combinatorial combinations of classes and roles
> > > into specific groups -- like having editor_book1, editor_book2,
> > > editor_book3, etc.
> >
> > With 'actions' you can do this quite easily. "Group X is allowed
> > to edit book1, but can only view book2." That's why I dislike
> > the term 'roles'; it implies a strict connection between 'groups'
> > and particular 'actions'.
>
> That's not what I was hoping for: that still means there has to be
> a group editor_of_book1, editor_of_book2, etc., while I'd like
> "editor" to be a role that is specific for a certain object (book1,
> book2, etc).
>
> Then you don't have to add more roles when you add more book
> objects: the roles can remain relatively static, and only be
> updated based on policy changes and such.
>
> I use roles like groups, except "group" feels more concrete, and
> I'm talking about something a bit more abstract.
Ok, I see what you're getting at now. In that case, a 'role' is a
set of permissions to perform certain actions on an resource. Users
and groups that are given the 'role' editor for a resource are
allowed to edit but not delete it. By allowing a group to belong to
other groups you get this behaviour. What you're suggesting would
internally be implemented like this anyway ('editor_of_book1'). The
question then, is whether the implementation details should be hidden
from the user.
> > Why are ACL's hard to manage?
>
> Management of ACL's is very imperative. For instance, in my
> example, when you wanted to change something about how a group
> related to articles -- like, say, you want editors to no longer be
> able to delete articles -- then you'd have to go through all the
> articles and change the permissions for each one. Tools make this
> easier, but they don't make it cleaner.
>
> I don't have a ton of experience with such things, but I found it
> quite difficult to figure out what the situation was in NT with
> permissions in many cases -- viewing each file's permissions is a
> lousy way to do an audit.
There are ways to allow inheritance of permissions that would get
around this.
> I think there needs to be more opportunities for abstraction in the
> permission system. Also, a more declarative model might be easier
> to manage.
More declarative in what sense??
> > > I don't think ownership is a necessary metaphor, though
> > > sometimes it is a useful metaphor. Sometimes it is
> > > meaningless.
> >
> > I agree that in most cases the concept of ownership will be
> > meaningless, but some of the AppIdeas on the Webware Wiki would
> > need this concept. So it's best to build it into the base
> > system.
>
> I don't think things should be built in because they might be
> needed -- instead we should build a structure where they can be
> implemented as needed. I don't want everything to have an owner
> just because a few things need ownership, just like everything
> shouldn't have an executable bit, etc.
I just mean for the hooks to be built-in. That would not require
that everything have an owner.
> > > The conventional security in Webware is pretty much a
> > > throw-exception-when-necessary system.
> >
> > That's another thing that needs some thought: what happens when a
> > user is authentificated, but tries to access a resoure they don't
> > have permissions for. There should be hooks for custom logging
> > and forwarding.
>
> Well, I think it should just throw an exception, and at some point
> you might catch that exception, log it, and forward or request they
> login or something.
>
> The permission error might very well happen somewhere there's no
> access to the larger context. Which is where exceptions are so
> nice (I love exceptions!) If you build in introspection, that
> might involve checking if an exception is thrown (like hasattr
> works, I think), or it might mean that permission information is
> built into the object, and an exception is thrown when illegal
> access is made. Actually handling that exception is just a matter
> of it being caught somewhere, like in Servlet, perhaps.
Yeah, that makes sense. So it's just a matter of providing an
exception handler for unhandled permission exceptions.
> > Correct me if I'm wrong, but it seems that UserKit can't be used
> > with non-servlet files.
>
> As far as I can tell UserKit has absolutely no web-based or
> webkit-based assumptions. It is totally seperated. It also
> doesn't address anything to do with permissions, just users. It's
> quite minimal.
Ok, then so the only way to use UserKit to manage permissions for
non-servlet files would be to call it from the Application class like
I was suggesting.
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
