You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jacco van Weert <11...@gmail.com> on 2009/01/16 09:29:33 UTC
AccessManager in Jackrabbit v1.5
Hello,
I am currently adapting the JeCARS custom accessmanager for Jackrabbit v1.5.
There is a "strange" thing I encounter while developing.
I see that when a new JCR object is created, before it is actually created
an READ permission is asked of the jcr:created property.
Because I override the isGranted() method I expect the object being created
before(!) the READ check.
How do I act in this case?
Does a subclassed AccessManager has access to the internal object cache?
Greetings,
Jacco
--
-------------------------------------
Jacco van Weert -- 1111software@gmail.com
JCR Controller -- http://www.xs4all.nl/~weertj/jcr
JeCARS -- http://jecars.sourceforge.net
Re: AccessManager in Jackrabbit v1.5
Posted by Angela Schreiber <an...@day.com>.
hi ivo
> Getting back to your suggestion, is the "super" session able to see
> itemstate for item, which is not yet persisted and is actually "owned" by
> the session subject of authorization?
no... that's why i said that "you need to operate on the itemstate
level instead, if you want to retrieve characteristics of transient
items ...". what i meant was: new items or transient modifications.
> Having the state, can the session obtain the item itself and read its
> properties?
obtaining the "itemstate" instead of the items. take a
look at the jackrabbit internals... there is no way to
circumvent that, if you want to write a custom access
manager which is part of that interal structure.
regards
angela
Re: AccessManager in Jackrabbit v1.5
Posted by Ivo Kolev <iv...@dir.bg>.
Hallo, Angela,
Thanks for spending time on my issue.
As I described in my previous post, to evaluate the permissions to be
granted to a session, I'm using impersonation. Thus, I'm getting a new
session having full access, hence, able to see any item, interrogate its
attributes and return proper answer to the first session - allow or deny the
permission.
Unfortunately, this does not work when creating new items. They are not yet
persisted and the "super" session cannot see them.
Getting back to your suggestion, is the "super" session able to see
itemstate for item, which is not yet persisted and is actually "owned" by
the session subject of authorization?
Having the state, can the session obtain the item itself and read its
properties?
Cheers, Ivo Kolev
--
View this message in context: http://n4.nabble.com/AccessManager-in-Jackrabbit-v1-5-tp542582p1838243.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: AccessManager in Jackrabbit v1.5
Posted by Angela Schreiber <an...@day.com>.
hi ivo
> I need help on this Jackrabbit AccessManager.
> I have custome AccessManager, providing access security based on the logged
> account and the permissions an account has. Basically, the permissions apply
> over a folder (kind of) - one can see a folder, put some items in it, edit
> these items, etc. The type of items a folder can accomodate is also part of
> the security.
>
> My problem in particular concerns the creation of item in some folder. In
> this case, AccessManager.isGranted(path, perm) is called to resolve the
> access. I'm trying to get the new-created item from the session in order to
> check its type and if it is applicable to the folder security settings. This
> is done through ItemManager and HierarchyManager. The call gets back to
> AccessManager.isGranted asking for read permission. Eventually, I'm getting
> into a dead loop.
if i'm not mistaken you are using the same session and the
same API calls for the permission checking than for the
access. that won't work.
i think you need to operate on the itemstate level instead,
if you want to retrieve characteristics of transient items
in the access manager.
similarly you must use a different (system) session to
evaluate access control if it is stored in the content. you
cannot use the one your are evaluating the permissions for.
regards
angela
> For the other operations I'm using session impersonation with some super
> account, having read permission everywhere.
>
> So, does anyone can help with this? I guess I'm not the first fighting this
> problem. Thanks.
>
> Cheers, Ivo Kolev
Re: AccessManager in Jackrabbit v1.5
Posted by Ivo Kolev <iv...@dir.bg>.
Hallo,
I need help on this Jackrabbit AccessManager.
I have custome AccessManager, providing access security based on the logged
account and the permissions an account has. Basically, the permissions apply
over a folder (kind of) - one can see a folder, put some items in it, edit
these items, etc. The type of items a folder can accomodate is also part of
the security.
My problem in particular concerns the creation of item in some folder. In
this case, AccessManager.isGranted(path, perm) is called to resolve the
access. I'm trying to get the new-created item from the session in order to
check its type and if it is applicable to the folder security settings. This
is done through ItemManager and HierarchyManager. The call gets back to
AccessManager.isGranted asking for read permission. Eventually, I'm getting
into a dead loop.
For the other operations I'm using session impersonation with some super
account, having read permission everywhere.
So, does anyone can help with this? I guess I'm not the first fighting this
problem. Thanks.
Cheers, Ivo Kolev
--
View this message in context: http://n4.nabble.com/AccessManager-in-Jackrabbit-v1-5-tp542582p1836979.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: AccessManager in Jackrabbit v1.5
Posted by Angela Schreiber <an...@day.com>.
hi jacco
> Okay.... should I make a JIRA entry?
that would be nice. thanks.... otherwise
i would have created one ;)
angela
Re: AccessManager in Jackrabbit v1.5
Posted by Jacco van Weert <11...@gmail.com>.
Hello Angela,
Okay.... should I make a JIRA entry?
Gr.
Jacco
On Fri, Jan 16, 2009 at 5:28 PM, Angela Schreiber <an...@day.com> wrote:
> hi jacco
>
> let me take a closer look at this next week.
>>
>
> ... at a first glance, i assume that there is a bug in
> NodeImpl: the corresponding call creating a new child
> node does in fact use a diffent way to access the item.
> that's probably wrong with createChildProperty.
>
> i'll verify it (still next week ;) and keep you informed.
>
> regards
> angela
>
>
--
-------------------------------------
Jacco van Weert -- 1111software@gmail.com
JCR Controller -- http://www.xs4all.nl/~weertj/jcr
JeCARS -- http://jecars.sourceforge.net
Re: AccessManager in Jackrabbit v1.5
Posted by Angela Schreiber <an...@day.com>.
hi jacco
> let me take a closer look at this next week.
... at a first glance, i assume that there is a bug in
NodeImpl: the corresponding call creating a new child
node does in fact use a diffent way to access the item.
that's probably wrong with createChildProperty.
i'll verify it (still next week ;) and keep you informed.
regards
angela
Re: AccessManager in Jackrabbit v1.5
Posted by Angela Schreiber <an...@day.com>.
hi jacco
i see... the property is accessed during the creation of the
autocreated properties.... that's why.
let me take a closer look at this next week.
kind regards
angela
Re: AccessManager in Jackrabbit v1.5
Posted by Jacco van Weert <11...@gmail.com>.
Hello Angela,
I've tried it.
I perform an addNode() and my own accessmanager the isGranted() method is
override'd and performs the following code;
String perm = null;
NodeId nodeId = mHierMgr.resolveNodePath( pPath );
PropertyId propId = null;
if (nodeId==null) {
propId = mHierMgr.resolvePropertyPath( pPath );
System.out.println("path = " + pPath.toString() );
// **** TODO is this ok?... it happens when a new object is
created and the accessmanager ask for read access on a property.
// if (propId==null) return true;
nodeId = propId.getParentId();
}
this is the System.out.println result
path = {} {}JeCARS {}default {}Groups
{}testGroup {http://www.jcp.org/jcr/1.0}created
and the stacktrace
at org.jecars.CARS_AccessManager.isGranted(CARS_AccessManager.java:844)
at org.jecars.CARS_AccessManager.isGranted(CARS_AccessManager.java:806)
at org.apache.jackrabbit.core.ItemManager.canRead(ItemManager.java:339)
at org.apache.jackrabbit.core.ItemManager.canRead(ItemManager.java:326)
at
org.apache.jackrabbit.core.ItemManager.createItemData(ItemManager.java:696)
at org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:291)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:228)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:493)
at
org.apache.jackrabbit.core.NodeImpl.createChildProperty(NodeImpl.java:479)
at org.apache.jackrabbit.core.NodeImpl.createChildNode(NodeImpl.java:535)
at
org.apache.jackrabbit.core.NodeImpl.internalAddChildNode(NodeImpl.java:795)
at org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:729)
at org.apache.jackrabbit.core.NodeImpl.internalAddNode(NodeImpl.java:677)
at org.apache.jackrabbit.core.NodeImpl.addNode(NodeImpl.java:2110)
On Fri, Jan 16, 2009 at 10:29 AM, Angela Schreiber <an...@day.com> wrote:
> hi jacco
>
> I see that when a new JCR object is created, before it is actually created
>> an READ permission is asked of the jcr:created property.
>>
>
> in the item manager there is always a check for READ permission
> on the id/path before the corresponding jcr item is created (or returned).
>
> but the jcr:created property doesn't have any relation to that.
> can you check where that comes from?
>
> Because I override the isGranted() method I expect the object being
>> created
>> before(!) the READ check.
>>
>
> you mean the item? you can't expect that.
>
> regards
> angela
>
--
-------------------------------------
Jacco van Weert -- 1111software@gmail.com
JCR Controller -- http://www.xs4all.nl/~weertj/jcr
JeCARS -- http://jecars.sourceforge.net
Re: AccessManager in Jackrabbit v1.5
Posted by Angela Schreiber <an...@day.com>.
hi jacco
> I see that when a new JCR object is created, before it is actually created
> an READ permission is asked of the jcr:created property.
in the item manager there is always a check for READ permission
on the id/path before the corresponding jcr item is created (or returned).
but the jcr:created property doesn't have any relation to that.
can you check where that comes from?
> Because I override the isGranted() method I expect the object being created
> before(!) the READ check.
you mean the item? you can't expect that.
regards
angela