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 13:45:11 GMT

not sure that i understand what you are saying.
jackrabbit does check for sufficient permission to remove
a node or property in the run of the save call.

as far as i understood you are having your custom
implementation of the access manager and run into troubles
while upgrading to a more recent version. can you provide
a test that illustrates the problem?

kind regards

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

>I am facing a "issue" in my rules when a user in the session invokes the
>The api did not call the "isGranted(Path absPath, int permissions)" in
>invoke to remove(), but when the user calls session.save() the
>"isGranted(Path absPath, int permissions)" method is entered but the
>item/properties is not there anymore and the operation is permited and
>saved, but the user was not with that permission to remove the node... so,
>how to check the remove permission when the ItemManager will not find to
>node to check this (this happens independently if the user has or not the
>remove permission).
>I did a call to "checkPermission" before invoke the "remove" as a
>workaround, but I think the api would check this on demand by the
>org.apache.jackrabbit.core.security.AccessManager implementation, not???
>I am doing my own rules to achieve the rights for the user, and my
>implementation was based on version 1.4, and now after upgrading to 2.6.3
>needed to adequate the levels of permissions and methods of the interface
>AccessManager, but it seems that the api changed the way to check the
>permissions and it is not like in version 1.4 at least for the
>I will apreciate any directions of help,
>View this message in context:
>Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

View raw message