> > >3 more things: > > > >- I sync'd to cvs and don't see your changes. Got the JAAS ones though. > > > > > Welcome to SourceForge. AFAIK they have a timed synchronisation from the > developer CVS servers to the anonymous access ones. So give it a few > hours (I received the commit messages to acegisecurity-cvs, so I know > they're there).
Ok. > > >- What is acl_class for? I don't see it used in your tests. > > > > > This is the BasicAclEntry instance created. I don't test for it > expressly in the unit tests because it has to be successful in order to > return anything from the JdbcDaoImpl. Ahh, I see now. This is like a permission type. I debated this idea here but could not find a use for it. I could not see how it would add info to what the permission meant. It seems that the recipient, accessed object, and mask conveyed everything I need to. I was planning on leaving it to the security framework to interpret the class of permission on the fly. In this way it is also polymorphic in nature. > > >- I forgot, below is how I have had to model it. I would think it is to > >complex for a base implementation but I just wanted you to see what I > >must handle for our product. Notice we are using integers instead of > >varchar for all acl lookups. > > > We could make all "recipients" (roles and users) need an entry in > acl_object_identity, then use a FK to it from acl_permission.recipient. > The issue is it would require every possible recipient to have an entry > in acl_object_identity, when by their nature they already have other > tables within an application (usually the users and roles tables). > > I would assume most applications don't need the flexibility of treating > users and roles as both "recipients" as well as "domain object > instances" for which permissions can be assigned against. Is that what > you're trying to do? Yes. Not sure if you saw my previous post since you replied to this one. But I think it is a common use case to have specific users edit specific users' data. I am not saying to include this ability in your base design just that is common. Besides when I get done with my implementation, I will try and submit anything applicable to you for possible inclusion. But the farther you get with a base implementation really helps me out. I couldn't see a FK mapping to > acl_object_relationship so I wasn't 100%. > No, I purposefully drive everything off of the object_identity table. By association a recipient does not need a relationship entry but does require a entry in the object_identity table. > Perhaps we should provide an additional JDBC DAO provider with a view to > sharing a central table structure between authentication and ACLs. ie: > I think that is wise. > - Recipient table: id IDENTITY, type INTEGER (user or role), name > VARCHAR (username or rolename) Is this easier to implement than just putting this info into the object_identity table? Or is it better because you have a clear division between recipient and domain objects? This design is constraining to use cases such as mine but I can see the clarity in doing this. I figure on implementing my own dao anyway. I am using hibernate. > - Users table: recipient_id INTEGER (FK to Recipient), password VARCHAR, > email VARCHAR, lastLogin DATE, unsuccessfulPasswords INTEGER etc > - Role_member table: role_recipient_id, user_recipient_id This is exactly the parent-child relationship that I must implement. It made sense to me to put this in acl_object_relationship since my recipients must be domain objects as well. > - Acl_permission: change recipient to be an INTEGER (with FK to > Recipient table) > > This would still not address your requirement to also treat recipients > as domain object instances. But still, with an appropriate trigger > against the Recipient table you shouldn't have much difficulty auto > creating/deleting a corresponding row in the acl_object_identity table. > > Ben > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Acegisecurity-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
