I need to implement this anyway, so if you can wait I would be glad to help out. But I won't need to start this effort for awhile. It might be better for you do this until I get comfortable with the code. I am eager to contribute but I have non-instance based security to implement first (product priorities).
One other question, were you planning on implementing a voter for this functionality? I know you mentioned this earlier. By the way, your unit tests are great and really show how acegi should be properly used. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Ben Alex > Sent: Thursday, July 29, 2004 7:19 PM > To: [EMAIL PROTECTED] > Subject: Re: [Acegisecurity-developer] Instance based security > > March, Andres wrote: > > >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 :)). > > > > > I totally agree. In fact, the BasicAclProvider's Javadocs expressly > prohibit this type of complexity: > > "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 ------------------------------------------------------- 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
