thanks Angela, very much appreciated. On Wed, Feb 26, 2020, 7:07 PM Angela Schreiber <[email protected]> wrote:
> Hi Marco > > Yes, the extra note regarding performance was intended to remind people > that expensive calculations may have a negative effect on overall > permission evaluation performance. If the restriction check is fast, the > impact is most likely insignificant. But take for example the node type > name restriction: if one would change this to calculate the effective JCR > nodetype with all the inheritance and mixins it might be quite slow compare > to a simple string comparison. > > It's just a extra word of caution because I regretted more than once for > not being explicit in the documentation and assuming what I considered > common sense. Then realized later on that my understanding of common sense > in Oak is based on a bit of extra insight. Others may not necessarily have > that insight such as I am likely shortsighted or ignorant in other areas > 🙂 > > Hope that helps > Angela > ------------------------------ > *From:* Marco Piovesana <[email protected]> > *Sent:* Wednesday, February 26, 2020 11:51 AM > *To:* [email protected] <[email protected]> > *Subject:* Re: custom restrictions on ACEs > > hi Angela, > what I want is basically being able, when reading an ACE, to know if it was > created because of a user request or not. So having a property that I can > set when creating the ACE would have been sufficient. > I think that the default authorization process works fine for what I need, > so maybe implementing a custom one > might be an overkill, but thanks for the tip, I didn't know about the > examples. > I have one more question, the documentation says that: "restrictions are > part of the overall permission evaluation and thus may heavily impact > overall read/write performance", that depends on how much work is required > to validate the restriction right? if the validation itself is fast, then > the impact on the performance is very limited, or there are other things > that might decrease the performances? > > > On Wed, Feb 26, 2020, 5:25 PM Angela Schreiber <[email protected]> > wrote: > > > Hi Marco > > > > Depending on what you wish to achieve the restrictions may help. I am not > > sure if fully understood what you are aiming for so it's a bit hard to > tell > > if restrictions will really do the trick. > > > > Depending on the actual needs and how well your access control > > requirements fit into the default authorization model, it might be worth > > exploring the ability to provide a custom authorization setup. If you > find > > yourself struggling to map your needs to a setup using the default > > authorization, exploring a custom implementation might be worth the > effort > > and might also end up being more efficient in terms of maintaining the > > setup and evaluation performance... but it really depends on the details. > > In case you wish to explore that option, you will find some simplistic > > examples/exercises in the oak-exercise module. > > > > The same exercise module also provides a few exercise lessons for > > restrictions and how to write a custom restriction provider. Obviously > > that's a lot easier that writing a custom authorization model. > > > > Hope that helps > > Angela > > ________________________________ > > From: Marco Piovesana <[email protected]> > > Sent: Wednesday, February 26, 2020 9:13 AM > > To: [email protected] <[email protected]> > > Subject: custom restrictions on ACEs > > > > Hi all, > > I have an application where the ACEs (Access Control Entries) are applied > > to a node by users and by the system itself. By the user when she/he > wants > > to share the node with some other users, by the system when the node has > to > > be available to some users in automatic, under specific conditions. The > > user should not be able to modify an ACE added by the system. > > Right now, when I read the ACL, I can't tell what ACE has been created by > > the user and what has been created by the system. Reading the > documentation > > I saw that one possible solution might be using custom restrictions > > < > > > https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html > > > > > when creating the ACE, but I'm not sure this is one of the intended usage > > for the restrictions. Is there a better solution for this problem? > > > > Marco. > > >
