Hi, I too, was struggling with Slide role model, so I'll take this chance and try to share some information. It'd be great if someone in the know can clear all up.
> remark 1: > I'm not sure whether in Slide a user can have more than 1 role. > When I look at the users .def.xml file, I can only see that the > user has exactly 1 type, which is configured by the classname > attribute on the objectnode element. One would expect a user to > be configured with multiple roles It is possible. It seems you have found that out yourself, but you only need a class that implements multiple interfaces, each corresponding to specific role. That's why you map RootRole "interface" to root "role" while root "user" is mapped to RootRoleImpl "class" that implements it. > remark 2: > This type of the configured classname corresponds to a role and descends > from SubjectNode - ObjectNode. On all three classes I fail to find methods > that deal with roles. All *Node classes are just an object that represents node in tree-style storage structure. Security related checks are done in org/apache/slide/security/*.java classes. > 3. The vector of roles is build by using refelection on the role > implementation class. This presents a (academic) problem. Yes, this is a problem, but this wasn't apparent in current Slide usage. This happens because there're two hashtables in Slide: table that maintains role-to-class (interface) relation and user-to-class relation. In Slide, role checking is done by hasRole(), which looks up role-to- class table and then run a check by "roleClass.isInstance(userObject)". This will work even if you have defined new role interface that extends existing role. On the other hand, getRoles() looks up user-to-class table and only lists up directly implemented interfaces as you have pointed out. But since getRoles() is not used for security check, this bug was not apparent. > 4. Non role-related interfaces are included aswell. When the class > hierarchy is traversed, it is thinkable (again, maybe an academic > point) that interfaces are found that have nothing to do with roles > whatsoever. True. But this one isn't a problem as role interfaces are just a placeholder and has no callable method. It is handled as role interface if and only if you map it to specific role in Domain.xml. Anything else is just ignored. > 5. I not sure whether order of the vector is important. > [snip] > I think for now it would be save for getPrincipals() to take the > second role in getRoles() provided that your role implementation > class specifies the 'broadest' role as it's first interface: Hmm, I'm not sure. It sounds like you're saying Slide needs this "broadness" concept just because Cocoon has one. But anyway, what you have described is current limitation of Slide role model. Slide "role" is so inflexible that Slide "group" is actually more closer to use of "role" in other software. It probably does not worth much trying to use current Slide role, as this limitation is pretty painful. It'd be better to wait until this gets fixed. AFAIK, there was an attempt to fix this user/role/group model in late 2002. That would have solved many of the problems. I even remember seeing actual patch floating around, but I guess that effort went nowhere as I still don't see that patch applied in CVS. -- Taisuke Yamada <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
