Angela, Thanks for the help, but I think the problem I mentioned is real, and is a genuine problem.
Basically what I'm saying is this: If I add only JCR_ADD_CHILD_NODES privilege it fails to work. That privilege cannot work by itself. It only works if you add all three JCR_ADD_CHILD_NODES + JCR_NODE_TYPE_MANAGEMENT + JCR_WRITE. So it's either a bug, or it is a serious design mistake in the API itself, at least based on my reasoning. Because as I said, it's a common use case to have one user need to share a node with other users without giving those other users ability to EDIT what I shared. Like if i want people able to comment under my blog, I but I don't want people EDITING my blog. That's a sample use case. However it's not a showstopper. In my app "meta64.com", I just only allow a user to edit the content of a node if they are the CREATOR of the node. So I add that security hack on top of the core security. It's a hack, but the JCR seriously needs to address this, unless I'm making a mistake, which I don't think I am, because other users (StackOverflow) ran into this also. I probably should write this up as a BUG in the Jira and get the attention of the developers. Best regards, Clay Ferguson wcl...@gmail.com 214-957-5950 On Thu, Jul 30, 2015 at 9:33 AM, Angela Schreiber <anch...@adobe.com> wrote: > hi clay > > Privilege.JCR_ADD_CHILD_NODES indicates that you can create > > child nodes (without explicitly specifying the primary or mixin > types). if you wanted to use Node.addNode(String, String) > you additionally have to grant Privilege.JCR_NODE_TYPE_MANAGEMENT. > > however, as far as other, non-protected properties are concerned that > you want to add below your target node: > as of Oak 1.0 (rewrite of the JCR repository) the > Privilege.JCR_MODIFIY_PROPERTIES > privileges has been adjusted to actually be an aggregation of > _add_, _alter_ and _remove_ properties (thus reflecting the fact > that some applications only want people to _add_ content but not > provide them the ability to _modify_ it later on). those privileges are > define in JCR but come with a 'rep' prefix. in the old jackrabbit 2.x > this is not possible and Privilege.JCR_MODIFIY_PROPERTIES is > not an aggregate privilege. > > hope that helps > angela > > On 26/07/15 18:34, "Clay Ferguson" <wcl...@gmail.com> wrote: > > >Fellow Jackrabbits, > >I'm working on an "socia media" type application and trying to add a > >feature that allows a user to share a node with another user, but the > >person getting shared to should ONLY be able > > to ADD child nodes, and not actually edit the node being shared. This > >means I would like for Privilege.JCR_ADD_CHILD_NODES to actually do what > >it's name implies. But it doesn't. It seems that in order to get > >Privilege.JCR_ADD_CHILD_NODES to work, I *also* > > have to include Privilege.JCR_WRITE which I specifically do NOT want. > >Think of it like this: I have a blog node (for example), and I want > >people to be able to make comments on my blog under it but not edit my > >blog themselves. Am I doing something wrong? Should > > this work? > > > > > >The app is > >meta64.com <http://meta64.com> if anybody cares. > > > > > >β- β > >Clay Fergu > > > >βsonβ > > > > > > > > > > > >
