> I haven't been following all of this, but it sounds interesting and > worthwhile. Many of the ideas listed on the Wiki's AppIdeas page are > closely related to this idea. UserManagement is an essential > component of all the application ideas listed so far. > > Is UserKit up to the task? I haven't used it.
I haven't used it either, but I've looked at the code > Here's what I consider the essential aspects of a UserManagement > system: > > * secure authentification mechanism that works with or without cookies Not included > * concept of both users and groups (completely separate from the OS!) Yes, calls them roles. > * ability for one user to belong to multiple groups Of course > * ability for a group to belong to other groups Yes, I believe HiarRoles or something in UserKit does this > * flexible, role or action based, authorization (aka permissions) Does include permissions > * 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 > * 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 > * good logging This might be incidental to what UserKit actually does -- well, I don't think it is meant to *do* anything, only be a way to query information (about users) -- logging every query is very noisy. > * clean separation between the backend and the user-interface that > permits quick customization of the UI. Well, not including a UI makes for a clean seperation, I suppose :) What UserKit could really use is some good examples and docs -- not thorough, but more like a map. It didn't seem entirely clear to me how it fit together. The code itself seems very compact (all the more reason docs are important). I think permissions should be considered something of a different issue -- ACLs being traditional at this point, but not always appropriate. They are closely tied to the system's notion of a an object and the granularity of permissions. I myself have been thinking about a more OO way of doing permissions -- most of the ways seem to be based on static data structures with explicit algorithms: it's not possible, for instance, to say "anyone can do action X if someone with permission Y requested that they do it" -- you can make the request also grant the permission, but the algorithm itself is external to the security system. You can't, for instance, retroactively change those permissions around, because the actions (the request) have already passed. Anyway, I'm not sure where I'm going with that idea, but it might only be to say that figuring out permissions is distinct from managing users and their roles/groups, and probably more complicated. Ian _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
