jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Granted permission to remove operation
Date Thu, 12 Sep 2013 17:18:44 GMT

in fact all regular jcr-write operations (adding nodes, setting
properties as well as removing) are only checked for sufficient
permissions upon saving.

if i get you right, your access manager uses the same session
or it's associated ItemManager or ItemStateProvider that already
removed the item... if that's the case it obviously doesn't

so, what you would need to have is access to the persisted
state that doesn't have any transient modifications applied.
in the default implementation we used to do this using a
separate system session.
an alternative would be to keep the ItemStateManager
which still reflects the persisted state without the transient
modifications... but i don't know by heart if that's feasible.

kind regards

On 9/12/13 6:43 PM, "hsp" <piccinatto@ibest.com.br> wrote:

>Ok Angela, thanks by your attention,
>I see it in:
>NodeImpl.onRemove(NodeId p)
>So, if the permission was not checked against the node BEFORE invoke
>node.remove(), it will be removed for that session...
>In the run of save call, in the validateTransientItems method, line 700,
>call the isGranted method:
>But in my code, when I try to get the Item/Property by the path, I just
>can't because it doesn't exist anymore, so it is impossible to check if
>operation is permitted, at least in the way I store the nodes with the
>permission control as child nodes of the item being removed/checked... It
>would be great if you suggest me a proper way to rescue the item to
>Let's see a portion of my code, just the important code envolved (I think
>provide you a test case with my code will be problematic for me, anyway I
>will try to put/simulate the environment later...)
>View this message in context:
>Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message