You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Bart van der Schans <b....@onehippo.com> on 2012/07/03 10:55:02 UTC
Question about same name siblings and authorization
Hi all,
We running into a (potential) issue with same name siblings and
authorization and I would like to have some feedback before we try to
fix this (if needed at all).
The problem is as follows: we have the following structure:
-content
`news
`newsitem
|- item
`- item
The session has only permissions to read the second sns and not the
first one. I would expect that this session, which sees only one
"item" node would be able to get the node with:
session.getRootNode().getNode("content/news/newsitem/item")
But this will return "null" and similarly the
hasNode(content/news/item/item) will return false. The only way to get
the node seems to be with:
session.getRootNode().getNode("content/news/newsitem/item[2]")
Which is a bit odd, because how can the session know there is more
than one item sibling? Does anybody knows what the spec has to say
about this?
Regards,
Bart
Re: Question about same name siblings and authorization
Posted by Stefan Guggisberg <st...@gmail.com>.
On Tue, Jul 3, 2012 at 11:06 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Tue, Jul 3, 2012 at 10:55 AM, Bart van der Schans
> <b....@onehippo.com> wrote:
>> We running into a (potential) issue with same name siblings and
>> authorization and I would like to have some feedback before we try to
>> fix this (if needed at all).
>
> Your problem boils down to having "same name siblings" and
> "authorization" in the same sentence, or perhaps even having same name
> siblings in the first place. You're probably better off if you try to
> avoid the SNS feature entirely.
>
>> Which is a bit odd, because how can the session know there is more
>> than one item sibling? Does anybody knows what the spec has to say
>> about this?
>
> The spec leaves this open by explicitly allowing access control to
> leave gaps in the SNS sequence. It's not an elegant solution, but
> AFAIUI nobody really considered such interactions when the SNS feature
> was specified (IIUC it came up just as a logical consequence of the
> XML import feature).
correct.
FWIW, here's what the jcr 2.0 spec says WRT sns and access & control: [0] (22.5)
cheers
stefan
[0] http://www.day.com/specs/jcr/2.0/22_Same-Name_Siblings.html
>
> BR,
>
> Jukka Zitting
Re: Question about same name siblings and authorization
Posted by Ard Schrijvers <a....@onehippo.com>.
On Tue, Jul 3, 2012 at 11:39 AM, Stefan Guggisberg
<st...@gmail.com> wrote:
>>
>> Ah, thanks Jukka and Stefan for the quick replies.
>>
>> So the "compacts indices" mode for SNS is also allowed (as stated in
>> paragraph $22.5), but I suspect that may take quite some effort to
>> implement this in the current code base. And even then it probably
>> will come at the cost of some performance.
>
> i would guess that implementing session-local index compacting would
> result in pretty nasty code. apart from that i don't see any benefit in
> doing so as the current behavior is clearly spec-compliant.
I agree that indeed nothing in Jackrabbit should be changed, as it is
clearly according spec. We just have to find out a way to deal with
the legacy we have on this area
Ard
>
> cheers
> stefan
>
>>
>> Regards,
>> Bart
--
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142
US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com
Re: Question about same name siblings and authorization
Posted by Stefan Guggisberg <st...@gmail.com>.
On Tue, Jul 3, 2012 at 11:19 AM, Bart van der Schans
<b....@onehippo.com> wrote:
> On Tue, Jul 3, 2012 at 11:06 AM, Jukka Zitting <ju...@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Jul 3, 2012 at 10:55 AM, Bart van der Schans
>> <b....@onehippo.com> wrote:
>>> We running into a (potential) issue with same name siblings and
>>> authorization and I would like to have some feedback before we try to
>>> fix this (if needed at all).
>>
>> Your problem boils down to having "same name siblings" and
>> "authorization" in the same sentence, or perhaps even having same name
>> siblings in the first place. You're probably better off if you try to
>> avoid the SNS feature entirely.
>
> We are very aware of this, but unfortunately we are dealing with a bit
> of legacy here :-(
>
>>> Which is a bit odd, because how can the session know there is more
>>> than one item sibling? Does anybody knows what the spec has to say
>>> about this?
>>
>> The spec leaves this open by explicitly allowing access control to
>> leave gaps in the SNS sequence. It's not an elegant solution, but
>> AFAIUI nobody really considered such interactions when the SNS feature
>> was specified (IIUC it came up just as a logical consequence of the
>> XML import feature).
>
> Ah, thanks Jukka and Stefan for the quick replies.
>
> So the "compacts indices" mode for SNS is also allowed (as stated in
> paragraph $22.5), but I suspect that may take quite some effort to
> implement this in the current code base. And even then it probably
> will come at the cost of some performance.
i would guess that implementing session-local index compacting would
result in pretty nasty code. apart from that i don't see any benefit in
doing so as the current behavior is clearly spec-compliant.
cheers
stefan
>
> Regards,
> Bart
Re: Question about same name siblings and authorization
Posted by Bart van der Schans <b....@onehippo.com>.
On Tue, Jul 3, 2012 at 11:06 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Tue, Jul 3, 2012 at 10:55 AM, Bart van der Schans
> <b....@onehippo.com> wrote:
>> We running into a (potential) issue with same name siblings and
>> authorization and I would like to have some feedback before we try to
>> fix this (if needed at all).
>
> Your problem boils down to having "same name siblings" and
> "authorization" in the same sentence, or perhaps even having same name
> siblings in the first place. You're probably better off if you try to
> avoid the SNS feature entirely.
We are very aware of this, but unfortunately we are dealing with a bit
of legacy here :-(
>> Which is a bit odd, because how can the session know there is more
>> than one item sibling? Does anybody knows what the spec has to say
>> about this?
>
> The spec leaves this open by explicitly allowing access control to
> leave gaps in the SNS sequence. It's not an elegant solution, but
> AFAIUI nobody really considered such interactions when the SNS feature
> was specified (IIUC it came up just as a logical consequence of the
> XML import feature).
Ah, thanks Jukka and Stefan for the quick replies.
So the "compacts indices" mode for SNS is also allowed (as stated in
paragraph $22.5), but I suspect that may take quite some effort to
implement this in the current code base. And even then it probably
will come at the cost of some performance.
Regards,
Bart
Re: Question about same name siblings and authorization
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Jul 3, 2012 at 10:55 AM, Bart van der Schans
<b....@onehippo.com> wrote:
> We running into a (potential) issue with same name siblings and
> authorization and I would like to have some feedback before we try to
> fix this (if needed at all).
Your problem boils down to having "same name siblings" and
"authorization" in the same sentence, or perhaps even having same name
siblings in the first place. You're probably better off if you try to
avoid the SNS feature entirely.
> Which is a bit odd, because how can the session know there is more
> than one item sibling? Does anybody knows what the spec has to say
> about this?
The spec leaves this open by explicitly allowing access control to
leave gaps in the SNS sequence. It's not an elegant solution, but
AFAIUI nobody really considered such interactions when the SNS feature
was specified (IIUC it came up just as a logical consequence of the
XML import feature).
BR,
Jukka Zitting