March, Andres wrote:
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).3 more things:
- I sync'd to cvs and don't see your changes. Got the JAAS ones though.
- 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.
- I forgot, below is how I have had to model it. I would think it is toWe 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).
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.
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? I couldn't see a FK mapping to acl_object_relationship so I wasn't 100%.
Perhaps we should provide an additional JDBC DAO provider with a view to sharing a central table structure between authentication and ACLs. ie:
- Recipient table: id IDENTITY, type INTEGER (user or role), name VARCHAR (username or rolename)
- 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
- 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
