[Off-Topic] Property level security

[Markus Joschko <ma...@gmail.com>]

Hi,
I know this question is more appropriate on the jackrabbit mailinglist
but maybe somebody here can help me:
Is it possible to define ACLs for individual property actions on a
node. So that only some selected properties can be modified by a
specific group of users?

If yes, what are the implications for sling?

Thanks,
 Marksu

Re: [Off-Topic] Property level security

[Markus Joschko <ma...@gmail.com>]

> Finally, as noted before, if you do have use cases which fetch a lot of
> different nodes (or better say: in all cases) your repository will be much
> faster if you use a "local" persistence manager with no network connection
> and no roundtrips.

Yep, fine for the dev environment but in the prod environment we'll
most likely use
MySQL to benefit from the existing clustering structure.

Regards,
 Markus

Re: [Off-Topic] Property level security

[Alexander Klimetschek <ak...@adobe.com>]

On 17.01.11 15:42, "Markus Joschko" <ma...@gmail.com> wrote:
>Does jackrabbit really make a request per next() call on the children
>iterator or does it optimize and fetches all children (as long as the
>number is reasonable low) when retrieving the iterator?

For getNodes() it uses a LazyItemIterator that fetches only on next(). In
your use case you will probably rather use getNode("childnode"), where you
fetch node by node (since your application will most probably know what
the child nodes are).

But when talking about a few child nodes that won't make any difference at
all.

Finally, as noted before, if you do have use cases which fetch a lot of
different nodes (or better say: in all cases) your repository will be much
faster if you use a "local" persistence manager with no network connection
and no roundtrips.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [Off-Topic] Property level security

[Markus Joschko <ma...@gmail.com>]

> Also, the nodes are cached in Jackrabbit in-memory, so if you have
> repeated read-only access to those nodes, there will be no need to fetch
> them from the persistence manager again.

Does jackrabbit really make a request per next() call on the children
iterator or does it optimize and fetches all children (as long as the
number is reasonable low) when retrieving the iterator?

>
> But you touch a good point: generally it is good to have a higher property
> per node ratio - something like 5-10 properties per node. With 4 nodes per
> request however, it should still be fine!
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> Developer // Adobe (Day) // Berlin - Basel
>
>
>
>
>

Re: [Off-Topic] Property level security

[Alexander Klimetschek <ak...@adobe.com>]

On 13.01.11 08:25, "Markus Joschko" <ma...@gmail.com> wrote:
>I thought more in the direction of node traversal. Instead of loading
>just one node and checking ACLs I have to load the parent node and
>three childnodes to get a complete view. I have no idea how node
>retrieval is implemented in jackrabbit but given there is a database
>behind I fear that I have four db requests (parent+3 children) reads
>instead of one to create my view.

This depends on the persistence manager. The bundle DB persistence manager
will do that (one bundle per node), but if you use e.g. the embedded Derby
or H2 persistence managers, you don't have network latency.

Also, the nodes are cached in Jackrabbit in-memory, so if you have
repeated read-only access to those nodes, there will be no need to fetch
them from the persistence manager again.

But you touch a good point: generally it is good to have a higher property
per node ratio - something like 5-10 properties per node. With 4 nodes per
request however, it should still be fine!

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [Off-Topic] Property level security

[Markus Joschko <ma...@gmail.com>]

>
> I think this approach with a protected subnode should be fine - and no
> performance issue. ACL checks are done for every node anyway.
>
 I thought more in the direction of node traversal. Instead of loading
just one node and checking ACLs I have to load the parent node and
three childnodes to get a complete view. I have no idea how node
retrieval is implemented in jackrabbit but given there is a database
behind I fear that I have four db requests (parent+3 children) reads
instead of one to create my view.
Multiply this with several thousand and it can make a difference.

Regards,
 Markus

Re: [Off-Topic] Property level security

[Alexander Klimetschek <ak...@adobe.com>]

On 12.01.11 19:43, "Markus Joschko" <ma...@gmail.com> wrote:
>When property security is not an option I can only think about
>introducing a childnode containing the approver information which can
>be secured with the JCR capabilities.
>However I already have the requirement to also "protect" three other
>properties and I wonder what the performance impact might be when
>splitting the node into a parent and protected children.
>
>At every read operation of the parent node I then have to assemble all
>children to provide a view to the client.
>And the parent node is requested very often.
>Any thoughts on this?

I think this approach with a protected subnode should be fine - and no
performance issue. ACL checks are done for every node anyway.

Regards,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: [Off-Topic] Property level security

[Markus Joschko <ma...@gmail.com>]

OK, from posts on the jackrabbit mailinglist it looks like I should
give the Principalmanager a closer look.

Apart from that I wonder if I think in the wrong direction. Maybe
there is another way to deal with restricted properties?
The example I currently face is a property on a node which holds the
"Approver".  The approver property contains a reference to the user
who has to be notified/approve every change on a node.
Normal users can just read that property only a few (manual) selected
users can change that property. All the other properties on the node
can be modified by all users.

When property security is not an option I can only think about
introducing a childnode containing the approver information which can
be secured with the JCR capabilities.
However I already have the requirement to also "protect" three other
properties and I wonder what the performance impact might be when
splitting the node into a parent and protected children.

At every read operation of the parent node I then have to assemble all
children to provide a view to the client.
And the parent node is requested very often.
Any thoughts on this?

Thanks,
 Markus



On Mon, Jan 10, 2011 at 10:46 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> Well, this is really a question for the JCR EG, but... no, this isn't part
> of the JCR specification.
>
> On Mon, Jan 10, 2011 at 4:39 PM, Markus Joschko <ma...@gmail.com>wrote:
>
>> Hi,
>> I know this question is more appropriate on the jackrabbit mailinglist
>> but maybe somebody here can help me:
>> Is it possible to define ACLs for individual property actions on a
>> node. So that only some selected properties can be modified by a
>> specific group of users?
>>
>> If yes, what are the implications for sling?
>>
>> Thanks,
>>  Marksu
>>
>

Re: [Off-Topic] Property level security

[Justin Edelson <ju...@justinedelson.com>]

Well, this is really a question for the JCR EG, but... no, this isn't part
of the JCR specification.

On Mon, Jan 10, 2011 at 4:39 PM, Markus Joschko <ma...@gmail.com>wrote:

> Hi,
> I know this question is more appropriate on the jackrabbit mailinglist
> but maybe somebody here can help me:
> Is it possible to define ACLs for individual property actions on a
> node. So that only some selected properties can be modified by a
> specific group of users?
>
> If yes, what are the implications for sling?
>
> Thanks,
>  Marksu
>