On Tuesday 20 November 2001 01:00 pm, Ian Bicking wrote: > >�* a user-info interface (passwd-change, personal data, etc) > >�* web-based and command-line management interfaces that allows quick > >�drill-downs on users/groups and addition/update/suspension/deletion > >�of those users/groups > > No, probably by design
Well as the primary author of UserKit, I wouldn't say "by design" so much as "haven't gotten there". I would certainly like to see interface elements come with UserKit, probably under a UserKit/WebKit/ package. eg, the UserKit UI would be an optional integration with WebKit. > >�* support for multiple data stores(flat file, BDB, various relational > >�databases, etc.) > >�* ability to tie into existing databases without needing to migrate > >�data (i.e. soft-code the fields used) > > It does have flat file and MK -- that implies other stores wouldn't be > hard I'm glad you noticed that. :-) On Tuesday 20 November 2001 02:10 pm, Ian Bicking wrote: > It's not at all clear to me, now, what an object is in Webware, with > respect to permissions -- obviously not every object is going to have > permission information. �Not every object is viewable. Geoff and I have played around with some designs for permissions. Interesting questions came up: - Do you ask the user object if he has permission to do X to Y, or do you ask Y if user U can do X? - How should permissions be archived? Particularly in MiddleKit. - Permissions should obviously speak of roles. Should they also be able to speak of specific users? The answers are left as an exercise to the reader. ;-) On Tuesday 20 November 2001 02:27 pm, Tavis Rudd wrote: > Ah, but 'groups' are not the same things as 'roles'. �I'm using > 'groups' in the traditional unix sense of the term, but with the > proviso that a group can belong to other groups. �'roles' are > something completely different. A better term for 'roles' is > 'actions'. In the context of web publishing, actions could include > the following: view, edit, delete, rollback, publish, hide, etc. It's immediately obvious that actions are always verbs: what can you _do_. Therefore, I don't see why these verbs would be considered "roles" which are nouns, in the non-action oriented sense. UserKit's roles *are* equivalent to groups. I chose the name "role" simply because I like it better and to avoid any implicit connection that they came from your op sys's groups. Plus we save one character of typing every time we say "role" instead of "group". ;-) On Tuesday 20 November 2001 02:27 pm, Tavis Rudd wrote: > Who's using UserKit??? Chuck, Tom, Geoff? anyone else? I'm using UserKit on a commercial project. In fact, that project funded about half of what's been developed there. However, the UI related to it is baked into the app and we haven't even tackled the permissions issue in any sensible way. On Tuesday 20 November 2001 03:34 pm, Tavis Rudd wrote: > Let's scrap the term 'role' completely then, and only use the terms > of users, groups, actions and permissions. �Where 'actions' are > things like view, edit, etc. and permissions are the authorization > for particular users and groups to be able to perform those actions > on an object. �An application designer should be able to define > custom actions. See my comment above. "Role" is already there and I'd like to stick with it. > And how about the term 'resource' rather than 'object'? I think this adds another conceptual layer that will obscure more than enlighten. At least that's my thoughts until I see some text that spells things out some more. > We also need to clarify the distinction between 'ownership' and > 'permissions'. �In Unix these concepts are directly tied together. > Not so in NT and other OSes. �It should be possible for multiple > users and multiple groups to have permissions to do perform various > actions on a resource, just like in NT. �But then who owns the > resource? �Should there be a concept of ownership built directly into > the system, where only the owner of a resource (and root) can changes > permissions for that resource. My first impressions is "no". We don't need to require a sense of ownership as part of providing a framework for user management and permissions. In fact, granular permissions about who-can-do-what seem to obviate the need for ownership. If an object knows that "chuck can *; tavis can view, edit, delete; others can view" then ownership becomes useless (unless you had other uses intended for it). Of course, permissions shouldn't interefere with adding ownership to objects. On Tuesday 20 November 2001 03:34 pm, Tavis Rudd wrote: > >�Well, we can start with authentication if it means we just use > >�UserKit, because using code that exists is very easy :) > > If it's suitable. UserKit isn't very prolific but what's there is well designed and tested. In fact, we designed the API together on the mailing list before writing the code. It was fun. :-) Nothing in UserKit would prevent adding in more things like UI, permissions, etc. On Tuesday 20 November 2001 03:34 pm, Tavis Rudd wrote: > I think that's going to be very context specific. �Pages with > distinct URI's are objects, but what about the UI components inside > those pages. �That's something that best left up to the application > designer. In my commercial project, it's the middle objects that are resources to be protected, where as the pages are the implementors of actions (like View.py eg http://localhost/webkit/app/Documents/View.py?doc=foobar). Various sites will take different approaches and I hope whatever permissions framework we come up with is flexible enough for that. At the heart of the design Geoff and I discussed was the method: def userCanPerform(self, user, action): Where users is a UserKit.User and action is a string such as 'view', 'edit', 'create', etc. You might need to flip that method a bit depending on whether your approach asks the user, or the object, or the role. A Permissable mix-in might provide a default implementation and/or convenience methods. Classes could override to do things like chaining of permissions. On Tuesday 20 November 2001 05:10 pm, Tavis Rudd wrote: > Correct me if I'm wrong, but it seems that UserKit can't be used with > non-servlet files. UserKit is currently used to provide a user manager, users, roles, hierarchical roles and persistence (via filesystem or middlekit). That doesn't preclude it from being extended or expanded in some way. On Tuesday 20 November 2001 07:21 pm, Darryl VanDorp wrote: > IIRC in the docs it says middlekit can't actually delete anything yet. > Certainly something of importance. No longer true. MK has deletes now. And let's never forget that while all frameworks having missing features, including MK and UK, that doesn't preclude us from extending them rather than shunning them or even worse, reinventing them. BTW MK has the best test suite of any Webware component. On Tuesday 20 November 2001 09:11 pm, Tavis Rudd wrote: > 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 Couldn't a role just be a label? While it might be true that the "editor" role can edit any document on your site, you might later choose to customize one document (say the corporate mission) with permission specs that say "editor cannot edit this". I'd rather edit the custom permissions for the corporate mission, than refactor my roles. On Tuesday 20 November 2001 09:28 pm, Ian Bicking wrote: > In the more general sense, you might want to have relations. �A person > can "own" something, perhaps another person is the "creator", or > "manager", etc. �I suppose that's what you were thinking of as > roles...? �Ownership could just be another role. > > Okay, I think we've got three ideas of roles just in this one email. > Damn terminology. If you're going to say person X is manager of Y, then I think the right term would be relationship. My idea of permissions though is oriented towards verbs: X can delete Y. That is so much more immediately obvious. On Wednesday 21 November 2001 10:21 am, Tavis Rudd wrote: > But you can't 'import' when you're working with non-servlet files! � > How would you protect static content without using Application (or > some funky path manipulations)? Last I checked, all content in WebKit had to go through some kind of servlet that originally came from a servlet factory. Or perhaps the upcoming URL manipulation hooks will provide a place to do this. I'm tired. See ya tomorrow. -Chuck _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
