March, Andres wrote:
I totally agree. In fact, the BasicAclProvider's Javadocs expressly prohibit this type of complexity:What I thought would result in no duplicated data is to break the relationship between the object and parent into its own table:
CREATE TABLE acls ( object_identity VARCHAR_IGNORECASE(250) NOT NULL, recipient VARCHAR_IGNORECASE(100) NOT NULL, mask INTEGER NOT NULL, acl_class VARCHAR_IGNORECASE(250) NOT NULL, CONSTRAINT pk_acls PRIMARY KEY(object_identity, recipient) ); CREATE TABLE object_relationships ( object_identity VARCHAR_IGNORECASE(250) NOT NULL, parent_object_identity VARCHAR_IGNORECASE(250), CONSTRAINT pk_objsrel PRIMARY KEY(object_identity, parent_object_identity) ); Where recipient could have one to many parents in the object_relationships table. Sorry about the column naming in object_relationships but for me recipients are just objects too.
The only issue here is if you wanted the acl to depend on the
relationship of the object to its parent. This could be required if you
want to have different permissions on object A by recipient B with
parent C versus parent D. I think this is overly complicated for a base
implementation and very rare. In fact I would be happy with a base
implantation that did not deal with parent relationships at all (but it
was really cool that you added it :)).
"NB: inheritance occurs at a <I>domain instance object</I> level. It does not occur at an ACL recipient level. This means <B>all</B><code>BasicAclEntry</code>s for a given domain instance object <B>must</B> have the <B>same</B> parent identity, or <B>all</B><code>BasicAclEntry</code>s must have <code>null</code> as their parent identity."
So the sort of exotic "Instance=Domain:2/Recipient=marissa/Parent=Domain:3" should never be used along with "Instance=Domain:2/Recipient:scott/Parent=Domain:66666". The latter should also be "Parent=Domain:2".
Your schema change suggestion would be highly beneficial in enforcing this behaviour. I just kept it at one table for simplicity's sake (people can see more easily what is going on) but now that I'm reflecting on it, I think your changes are most worthwhile. Would you like to send me a patch, or should I make the changes?
Best regards 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
