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. Now, this exactly functionality shouldn't be built into the system, of course, but hooks should be there. In my OO notion, lets say each user has an authentication object. That authentication object can represent composites of other authentication objects, each of which could be specialized in some way, i.e., you'd be making subclasses -- like I'd make a "role for book X" subclass that could deal with a role being directed to a book, with an "editor" instance that might be given to a particular user. Then the resources might have a, um, permission object. I'm still not sure how that would work, though... > > But I haven't seen a lot of other techniques. Capabilities seem to > > be ACLs where the action part is better abstracted... but otherwise > > I haven't seen why it is significantly different. But maybe I'm > > missing something there. ACLs are really hard to manage. Unix > > permissions aren't flexible enough. If anyone knows of interesting > > ideas, I'd be most curious. > > 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. I think there needs to be more opportunities for abstraction in the permission system. Also, a more declarative model might be easier to manage. > > 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. > > 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. > 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. Ian _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
