I think that it is important that whatever approach is taken should not PRECLUDE the integration of slide with another source for user information. It is possible (and in fact is true in our case) that the user information will need to be pulled from a completely external system (e.g., LDAP or some other proprietary source).
Using the slide file system to store the information would allow us to write our own store that acts as a facade to whatever backend datasource we wanted to use... Dave Keyes > > Proposal One: Use the Slide File System > This is basically what I proposed last time: Move the roles onto the file > system, store the groups in their own collection, and user link-nodes to > create the associations. > To me this has the advantage of consistency. All the user related > information is stored in a logical way on the file-system. Additionally, it > may be possible to manipulate the groups and roles simply using the webdav > protocol, also practical. On the other hand, storing this security > information in the same place as the content can be a security hazard too. > Perhaps it would be better to prevent all webdav access to the groups... > Another big advantage of this proposal is that all the storage mechanisms > are already in place, and a core part of slide, much tested. The users are > stored with the same flexibility as the content, and the slide administrator > does not need to worry about aditional setup. An different way of storing > the users would require its own code, introduce new bugs and presumably add > to slide's configuration. > Proposal Two: Use a new storage system > Since the users, groups, roles and actions have little to do with the > content, there is no pressing reason (other than the practical ones listed > above) to store this information on the slide file-system. In fact it may be > more secure to put it elsewhere. A specific proposal might be to create a > kind of 'userdatabase' object and store all users, groups and roles in this. > The entire object could just be serialized to disk (or the slide fs), and > loaded again in one piece. The problem with this approach occurs when there > are tens of thousands of users, and the userdatabase object gets too large. > However, this might be an acceptable trade-off, since I would assume that > installations with more than 10000 webdav users are rare. > It is worth thinking about... My instincts tell me that the slide > file-system is a good way to go. It is all there for us, and gets tested by > the test-suite all the time. And it is easy for people to understand and > use. > In either case, I would propose an API for reading users and user > properties, checking role and group membership, and adding and removing > users, roles and groups. I don't think it is a good idea to manipulate the > node structure directly when creating a new user, and if such an API were > used, it would allow slide to change the way the users are stored without > too much trouble. The org.apache.catalina.UserDatabase is a good starting > point, and I already have some parts implemented. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
