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 read a good deal of your code but not any that deals with traversing
the parent relationship. From my perspective, I thought the child would
inherit all the permissions of the parent and extend it. This is a
grant based scenario (like the one I'm implementing). I believe it to
be much more complicated to implement overriding permissions where a
permission granted to the parent is removed for the child. Now I'm just
blathering.
Hope this clears up what I meant.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
Of
> Ben Alex
> Sent: Thursday, July 29, 2004 3:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Acegisecurity-developer] Instance based security
>
> March, Andres wrote:
>
> >Wow, great work Ben. One question though, shouldn't the parent-child
> >object identity relationship be maintained outside the ACL table
since
> >conceivably there will be many records for the same child?
> >
> >
> >
> >
> Hi Andres
>
> The current implementation is like this:
>
> CREATE TABLE acls (
> object_identity VARCHAR_IGNORECASE(250) NOT NULL,
> recipient VARCHAR_IGNORECASE(100) NOT NULL,
> parent_object_identity VARCHAR_IGNORECASE(250),
> mask INTEGER NOT NULL,
> acl_class VARCHAR_IGNORECASE(250) NOT NULL,
> CONSTRAINT pk_acls PRIMARY KEY(object_identity, recipient)
> );
>
> Each row with a parent who should contribute ACL information populates
> its parent_object_identity with the object_identity of its parent. IT
> can also be null if there is no parent. This approach is fairly
simple,
> and also allows children to have parents of different class types. So
> you might have a domain object ACL hierarchy like this: World:1 ->
> Region:4 (say Pacific) -> Country:61 (say Australia) ->
> AdministrativeArea:1 (say New South Wales) -> Locality:434 (say
> Belmont). This "different parent types" is a common requirement, as
you
> can assign the ACLs at the higher, parent objects (eg folders ->
files,
> orders -> orderLineItems, organisations -> employees etc).
>
> I'm not sure I know what you mean re maintaining the parent identity
> outside the ACL table. Could you post a schema to the list?
>
> 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
