Hi Richie, Unger Richard wrote: > Let me think about this... Basically, I think the goal should be to > implement a more 'conventional' system for how the roles work. The exact > details of the storage don't matter, I think. The main point is that users > expect, based on past experience, to be able to add and remove roles, and > assign them to users. Also, roles are a good, clean way to implement > security policies, and it seems to me completely compatible to slide's ACL > permissions system.
I'm not arguing about the value of roles, I agree they're a nice and important thing to have. > The real question is why the decision was made to associate each node in the > namespace with a role. For the users and groups this makes sense, but it is > not obvious to me why this is necessary for the other nodes. What is the > reason for this? It seems to me that the nodes should be associated with a > 'type' (eg: userNode, fileNode, collectionNode) rather than a role. Note that nodes can basically have more than one 'type' or 'role' if you take collections into account... in particular a user-node is also a collection-node. Currently there is the DAV:resourcetype property that determines whether the node is a collection, as well as the role, which determines whether the node is a user, for example. I believe that the DAV:resourcetype concept should be supported directly in Slide, probably by a new and improved role system, and become a live property. > However, to answer your question, my specific proposal would be the > following: > > 1) Create 3 special collections: users, groups and roles (by default in > /users /groups and /roles) > 2) Store the users in the users collection, as they have been so far. > 3) Store the groups in the groups collection, as collections with linkNodes > for each user belonging to the group. > 4) Store the roles in the roles collection, as collections with linkNodes > for each user or group that is a member of the role. Then, to repeat a question from my previous email, what is the difference between roles and groups?? The above description implies they are functionally identical. > 5) Define some more 'rules' about how it all works: eg: don't allow > singlegroupmembers, allow only alphanumeric characters for user, group and > role names, etc, to prevent degeneracies. Also, allow user nodes only as direct members of the users collection. > Your proposal also seems reasonable, but there is some issues: > * If we put the list of roles in the class for the node, changing the roles > will require rewriting the node. No, it would require *some* code to add/remove the role from the node. > * It seems to me that there is already some 'confusion' about the storage of > security data: The users and groups are stored on the slide fs, as > 'structure'. The ACLs and user Passwords are stored in the node revision > properties. And the roles are stored in the nodes themselves. I think it > would be better not to mix this up, and store the roles either on the slide > fs, like the users and groups, or store them in the node revision > properties, like the passwords. Add actions to the list of security-related entities that live in the Slide structure IMHO, having a node for every tiny piece of information maintained by Slide is overkill. Retrieving/storing/removing a node is *substantially* more expensive than just keeping a list of strings in the node. Actually, I would like see much *less* data stored as nodes, ideally only the *actual content*. But that of course is a quite radical point of view ;-). > Who did the work on the original system of roles and nodes? I would really > like to know what the reason was to make every node associated with a role, > and whether there is a need for this... That would be Remy and Dirk, AFAICT. There was also some talk about revamping the security subsystem for Slide 2.0, mainly initiated by Dirk, but it hasn't been further discussed since then. You might have luck searching the slide-dev archives. -- Christopher Lenz /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
