You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Tobias Bocanegra <tr...@apache.org> on 2013/10/31 19:34:41 UTC
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/java/or...
Hi,
> --- jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/ImmutableACL.java (original)
> +++ jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31 16:54:20 2013
> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
> }
>
> @Override
> + public boolean addEntry(Principal principal, Privilege[] privileges, boolean isAllow, Map<String, Value> restrictions, Map<String, Value[]> mvRestrictions) throws AccessControlException {
> + throw new AccessControlException("Immutable ACL. Use AccessControlManager#getPolicy or #getApplicablePolicies in order to obtain an modifiable ACL.");
> + }
> +
> + @Override
Can't we just use the "Map<String, Value[]> mvRestrictions" argument?
having both seems a bit awkward. or is there a difference if I specify
a restriction with an 1 value array or a restriction with 1 value?
Regards, Toby
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Tobias Bocanegra <tr...@apache.org>.
I see, the signature would be the same as only the generic type of the
map is different.
well, in this case we have to live with this :-)
regards, toby
On Thu, Oct 31, 2013 at 3:59 PM, Angela Schreiber <an...@adobe.com> wrote:
> ah that one... this was today :-)
> i added a new method as i didn't want to change the signature of
> the method that already existed.. and which will now still work
> the same way as they used to work. but maybe misread your post.
>
> kind regards
> angela
>
> On 10/31/13 11:51 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>
>>but in:
>>
>>http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java
>>/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.java?r1=15
>>37546&r2=1537545&pathrev=1537546
>>
>>you added a new method to the API yesterday, which I think could be
>>simplified.
>>Regards, Toby
>>
>>On Thu, Oct 31, 2013 at 3:43 PM, Angela Schreiber <an...@adobe.com>
>>wrote:
>>> hi
>>>
>>> what are you referring to?
>>> the JackrabbitAccessControlList hasn't been touched for ages. the
>>> addEntry method with the String-Value map has been there at least
>>> since 2.0... changing that (and adjusting all calls that use that
>>> method in jr-core) is definitely not what i want to do.
>>>
>>> kind regards
>>> angela
>>>
>>> On 10/31/13 11:39 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>
>>>>On Thu, Oct 31, 2013 at 2:27 PM, Angela Schreiber <an...@adobe.com>
>>>>wrote:
>>>>> hi
>>>>>
>>>>> this breaks existing code which IMHO is not an option.
>>>>
>>>>but the API change was just added yesterday for Jackrabbit 2.7.2
>>>>(JCR-3641) which is not released yet. So we still can change it.
>>>>Regards, Toby
>>>>
>>>>>
>>>>> kind regards
>>>>> angela
>>>>>
>>>>> On 10/31/13 8:29 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>>>
>>>>>>sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
>>>>>>I would object :-) and only use the following signature:
>>>>>>
>>>>>> boolean addEntry(Principal principal, Privilege[] privileges,
>>>>>>boolean isAllow, Map<String, Value[]> mvRestrictions)
>>>>>>
>>>>>>Regards, toby
>>>>>>
>>>>>>
>>>>>>
>>>>>>On Thu, Oct 31, 2013 at 11:55 AM, Angela Schreiber <an...@adobe.com>
>>>>>>wrote:
>>>>>>> this is public API and i don't want to break existing code.
>>>>>>>originally
>>>>>>> i thought that restrictions will never be multivalued, otherwise i
>>>>>>>would
>>>>>>> have defined the original extension differently (right away with an
>>>>>>>array).
>>>>>>>
>>>>>>> on the other hand i am sure that a given implementation of the OAK
>>>>>>> restriction provider will be very specific on whether a given
>>>>>>>restriction
>>>>>>> can/must be single value or multivalued.
>>>>>>>
>>>>>>> and i decided not to follow your other proposal (using separate
>>>>>>>interface
>>>>>>> for
>>>>>>> the restrictions in jackrabbit-api) and this would lead to major
>>>>>>>changes
>>>>>>> throughout
>>>>>>> the security api just to make it consistent... i felt that this is
>>>>>>>not
>>>>>>> worth
>>>>>>> the effort.
>>>>>>>
>>>>>>> kind regards
>>>>>>> angela
>>>>>>>
>>>>>>> On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>> ---
>>>>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/o
>>>>>>>>>ak
>>>>>>>>>/s
>>>>>>>>>pi
>>>>>>>>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>>>>>>>>> +++
>>>>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/o
>>>>>>>>>ak
>>>>>>>>>/s
>>>>>>>>>pi
>>>>>>>>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>>>>>>>>16:54:20 2013
>>>>>>>>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> @Override
>>>>>>>>> + public boolean addEntry(Principal principal, Privilege[]
>>>>>>>>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>>>>>>>>Map<String, Value[]> mvRestrictions) throws AccessControlException
>>>>>>>>>{
>>>>>>>>> + throw new AccessControlException("Immutable ACL. Use
>>>>>>>>>AccessControlManager#getPolicy or #getApplicablePolicies in order
>>>>>>>>>to
>>>>>>>>>obtain an modifiable ACL.");
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> + @Override
>>>>>>>>
>>>>>>>>Can't we just use the "Map<String, Value[]> mvRestrictions"
>>>>>>>>argument?
>>>>>>>>having both seems a bit awkward. or is there a difference if I
>>>>>>>>specify
>>>>>>>>a restriction with an 1 value array or a restriction with 1 value?
>>>>>>>>
>>>>>>>>
>>>>>>>>Regards, Toby
>>>>>>>
>>>>>
>>>
>
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Angela Schreiber <an...@adobe.com>.
ah that one... this was today :-)
i added a new method as i didn't want to change the signature of
the method that already existed.. and which will now still work
the same way as they used to work. but maybe misread your post.
kind regards
angela
On 10/31/13 11:51 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>but in:
>
>http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java
>/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.java?r1=15
>37546&r2=1537545&pathrev=1537546
>
>you added a new method to the API yesterday, which I think could be
>simplified.
>Regards, Toby
>
>On Thu, Oct 31, 2013 at 3:43 PM, Angela Schreiber <an...@adobe.com>
>wrote:
>> hi
>>
>> what are you referring to?
>> the JackrabbitAccessControlList hasn't been touched for ages. the
>> addEntry method with the String-Value map has been there at least
>> since 2.0... changing that (and adjusting all calls that use that
>> method in jr-core) is definitely not what i want to do.
>>
>> kind regards
>> angela
>>
>> On 10/31/13 11:39 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>
>>>On Thu, Oct 31, 2013 at 2:27 PM, Angela Schreiber <an...@adobe.com>
>>>wrote:
>>>> hi
>>>>
>>>> this breaks existing code which IMHO is not an option.
>>>
>>>but the API change was just added yesterday for Jackrabbit 2.7.2
>>>(JCR-3641) which is not released yet. So we still can change it.
>>>Regards, Toby
>>>
>>>>
>>>> kind regards
>>>> angela
>>>>
>>>> On 10/31/13 8:29 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>>
>>>>>sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
>>>>>I would object :-) and only use the following signature:
>>>>>
>>>>> boolean addEntry(Principal principal, Privilege[] privileges,
>>>>>boolean isAllow, Map<String, Value[]> mvRestrictions)
>>>>>
>>>>>Regards, toby
>>>>>
>>>>>
>>>>>
>>>>>On Thu, Oct 31, 2013 at 11:55 AM, Angela Schreiber <an...@adobe.com>
>>>>>wrote:
>>>>>> this is public API and i don't want to break existing code.
>>>>>>originally
>>>>>> i thought that restrictions will never be multivalued, otherwise i
>>>>>>would
>>>>>> have defined the original extension differently (right away with an
>>>>>>array).
>>>>>>
>>>>>> on the other hand i am sure that a given implementation of the OAK
>>>>>> restriction provider will be very specific on whether a given
>>>>>>restriction
>>>>>> can/must be single value or multivalued.
>>>>>>
>>>>>> and i decided not to follow your other proposal (using separate
>>>>>>interface
>>>>>> for
>>>>>> the restrictions in jackrabbit-api) and this would lead to major
>>>>>>changes
>>>>>> throughout
>>>>>> the security api just to make it consistent... i felt that this is
>>>>>>not
>>>>>> worth
>>>>>> the effort.
>>>>>>
>>>>>> kind regards
>>>>>> angela
>>>>>>
>>>>>> On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>>>>
>>>>>>>Hi,
>>>>>>>
>>>>>>>> ---
>>>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/o
>>>>>>>>ak
>>>>>>>>/s
>>>>>>>>pi
>>>>>>>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>>>>>>>> +++
>>>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/o
>>>>>>>>ak
>>>>>>>>/s
>>>>>>>>pi
>>>>>>>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>>>>>>>16:54:20 2013
>>>>>>>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>>>>>>>> }
>>>>>>>>
>>>>>>>> @Override
>>>>>>>> + public boolean addEntry(Principal principal, Privilege[]
>>>>>>>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>>>>>>>Map<String, Value[]> mvRestrictions) throws AccessControlException
>>>>>>>>{
>>>>>>>> + throw new AccessControlException("Immutable ACL. Use
>>>>>>>>AccessControlManager#getPolicy or #getApplicablePolicies in order
>>>>>>>>to
>>>>>>>>obtain an modifiable ACL.");
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + @Override
>>>>>>>
>>>>>>>Can't we just use the "Map<String, Value[]> mvRestrictions"
>>>>>>>argument?
>>>>>>>having both seems a bit awkward. or is there a difference if I
>>>>>>>specify
>>>>>>>a restriction with an 1 value array or a restriction with 1 value?
>>>>>>>
>>>>>>>
>>>>>>>Regards, Toby
>>>>>>
>>>>
>>
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Tobias Bocanegra <tr...@apache.org>.
but in:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/security/JackrabbitAccessControlList.java?r1=1537546&r2=1537545&pathrev=1537546
you added a new method to the API yesterday, which I think could be simplified.
Regards, Toby
On Thu, Oct 31, 2013 at 3:43 PM, Angela Schreiber <an...@adobe.com> wrote:
> hi
>
> what are you referring to?
> the JackrabbitAccessControlList hasn't been touched for ages. the
> addEntry method with the String-Value map has been there at least
> since 2.0... changing that (and adjusting all calls that use that
> method in jr-core) is definitely not what i want to do.
>
> kind regards
> angela
>
> On 10/31/13 11:39 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>
>>On Thu, Oct 31, 2013 at 2:27 PM, Angela Schreiber <an...@adobe.com>
>>wrote:
>>> hi
>>>
>>> this breaks existing code which IMHO is not an option.
>>
>>but the API change was just added yesterday for Jackrabbit 2.7.2
>>(JCR-3641) which is not released yet. So we still can change it.
>>Regards, Toby
>>
>>>
>>> kind regards
>>> angela
>>>
>>> On 10/31/13 8:29 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>
>>>>sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
>>>>I would object :-) and only use the following signature:
>>>>
>>>> boolean addEntry(Principal principal, Privilege[] privileges,
>>>>boolean isAllow, Map<String, Value[]> mvRestrictions)
>>>>
>>>>Regards, toby
>>>>
>>>>
>>>>
>>>>On Thu, Oct 31, 2013 at 11:55 AM, Angela Schreiber <an...@adobe.com>
>>>>wrote:
>>>>> this is public API and i don't want to break existing code. originally
>>>>> i thought that restrictions will never be multivalued, otherwise i
>>>>>would
>>>>> have defined the original extension differently (right away with an
>>>>>array).
>>>>>
>>>>> on the other hand i am sure that a given implementation of the OAK
>>>>> restriction provider will be very specific on whether a given
>>>>>restriction
>>>>> can/must be single value or multivalued.
>>>>>
>>>>> and i decided not to follow your other proposal (using separate
>>>>>interface
>>>>> for
>>>>> the restrictions in jackrabbit-api) and this would lead to major
>>>>>changes
>>>>> throughout
>>>>> the security api just to make it consistent... i felt that this is not
>>>>> worth
>>>>> the effort.
>>>>>
>>>>> kind regards
>>>>> angela
>>>>>
>>>>> On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>> ---
>>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak
>>>>>>>/s
>>>>>>>pi
>>>>>>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>>>>>>> +++
>>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak
>>>>>>>/s
>>>>>>>pi
>>>>>>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>>>>>>16:54:20 2013
>>>>>>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>>>>>>> }
>>>>>>>
>>>>>>> @Override
>>>>>>> + public boolean addEntry(Principal principal, Privilege[]
>>>>>>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>>>>>>Map<String, Value[]> mvRestrictions) throws AccessControlException {
>>>>>>> + throw new AccessControlException("Immutable ACL. Use
>>>>>>>AccessControlManager#getPolicy or #getApplicablePolicies in order to
>>>>>>>obtain an modifiable ACL.");
>>>>>>> + }
>>>>>>> +
>>>>>>> + @Override
>>>>>>
>>>>>>Can't we just use the "Map<String, Value[]> mvRestrictions" argument?
>>>>>>having both seems a bit awkward. or is there a difference if I specify
>>>>>>a restriction with an 1 value array or a restriction with 1 value?
>>>>>>
>>>>>>
>>>>>>Regards, Toby
>>>>>
>>>
>
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Angela Schreiber <an...@adobe.com>.
hi
what are you referring to?
the JackrabbitAccessControlList hasn't been touched for ages. the
addEntry method with the String-Value map has been there at least
since 2.0... changing that (and adjusting all calls that use that
method in jr-core) is definitely not what i want to do.
kind regards
angela
On 10/31/13 11:39 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>On Thu, Oct 31, 2013 at 2:27 PM, Angela Schreiber <an...@adobe.com>
>wrote:
>> hi
>>
>> this breaks existing code which IMHO is not an option.
>
>but the API change was just added yesterday for Jackrabbit 2.7.2
>(JCR-3641) which is not released yet. So we still can change it.
>Regards, Toby
>
>>
>> kind regards
>> angela
>>
>> On 10/31/13 8:29 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>
>>>sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
>>>I would object :-) and only use the following signature:
>>>
>>> boolean addEntry(Principal principal, Privilege[] privileges,
>>>boolean isAllow, Map<String, Value[]> mvRestrictions)
>>>
>>>Regards, toby
>>>
>>>
>>>
>>>On Thu, Oct 31, 2013 at 11:55 AM, Angela Schreiber <an...@adobe.com>
>>>wrote:
>>>> this is public API and i don't want to break existing code. originally
>>>> i thought that restrictions will never be multivalued, otherwise i
>>>>would
>>>> have defined the original extension differently (right away with an
>>>>array).
>>>>
>>>> on the other hand i am sure that a given implementation of the OAK
>>>> restriction provider will be very specific on whether a given
>>>>restriction
>>>> can/must be single value or multivalued.
>>>>
>>>> and i decided not to follow your other proposal (using separate
>>>>interface
>>>> for
>>>> the restrictions in jackrabbit-api) and this would lead to major
>>>>changes
>>>> throughout
>>>> the security api just to make it consistent... i felt that this is not
>>>> worth
>>>> the effort.
>>>>
>>>> kind regards
>>>> angela
>>>>
>>>> On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>>
>>>>>Hi,
>>>>>
>>>>>> ---
>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak
>>>>>>/s
>>>>>>pi
>>>>>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>>>>>> +++
>>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak
>>>>>>/s
>>>>>>pi
>>>>>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>>>>>16:54:20 2013
>>>>>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>>>>>> }
>>>>>>
>>>>>> @Override
>>>>>> + public boolean addEntry(Principal principal, Privilege[]
>>>>>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>>>>>Map<String, Value[]> mvRestrictions) throws AccessControlException {
>>>>>> + throw new AccessControlException("Immutable ACL. Use
>>>>>>AccessControlManager#getPolicy or #getApplicablePolicies in order to
>>>>>>obtain an modifiable ACL.");
>>>>>> + }
>>>>>> +
>>>>>> + @Override
>>>>>
>>>>>Can't we just use the "Map<String, Value[]> mvRestrictions" argument?
>>>>>having both seems a bit awkward. or is there a difference if I specify
>>>>>a restriction with an 1 value array or a restriction with 1 value?
>>>>>
>>>>>
>>>>>Regards, Toby
>>>>
>>
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Tobias Bocanegra <tr...@apache.org>.
On Thu, Oct 31, 2013 at 2:27 PM, Angela Schreiber <an...@adobe.com> wrote:
> hi
>
> this breaks existing code which IMHO is not an option.
but the API change was just added yesterday for Jackrabbit 2.7.2
(JCR-3641) which is not released yet. So we still can change it.
Regards, Toby
>
> kind regards
> angela
>
> On 10/31/13 8:29 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>
>>sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
>>I would object :-) and only use the following signature:
>>
>> boolean addEntry(Principal principal, Privilege[] privileges,
>>boolean isAllow, Map<String, Value[]> mvRestrictions)
>>
>>Regards, toby
>>
>>
>>
>>On Thu, Oct 31, 2013 at 11:55 AM, Angela Schreiber <an...@adobe.com>
>>wrote:
>>> this is public API and i don't want to break existing code. originally
>>> i thought that restrictions will never be multivalued, otherwise i would
>>> have defined the original extension differently (right away with an
>>>array).
>>>
>>> on the other hand i am sure that a given implementation of the OAK
>>> restriction provider will be very specific on whether a given
>>>restriction
>>> can/must be single value or multivalued.
>>>
>>> and i decided not to follow your other proposal (using separate
>>>interface
>>> for
>>> the restrictions in jackrabbit-api) and this would lead to major changes
>>> throughout
>>> the security api just to make it consistent... i felt that this is not
>>> worth
>>> the effort.
>>>
>>> kind regards
>>> angela
>>>
>>> On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>
>>>>Hi,
>>>>
>>>>> ---
>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/s
>>>>>pi
>>>>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>>>>> +++
>>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/s
>>>>>pi
>>>>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>>>>16:54:20 2013
>>>>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>>>>> }
>>>>>
>>>>> @Override
>>>>> + public boolean addEntry(Principal principal, Privilege[]
>>>>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>>>>Map<String, Value[]> mvRestrictions) throws AccessControlException {
>>>>> + throw new AccessControlException("Immutable ACL. Use
>>>>>AccessControlManager#getPolicy or #getApplicablePolicies in order to
>>>>>obtain an modifiable ACL.");
>>>>> + }
>>>>> +
>>>>> + @Override
>>>>
>>>>Can't we just use the "Map<String, Value[]> mvRestrictions" argument?
>>>>having both seems a bit awkward. or is there a difference if I specify
>>>>a restriction with an 1 value array or a restriction with 1 value?
>>>>
>>>>
>>>>Regards, Toby
>>>
>
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Angela Schreiber <an...@adobe.com>.
hi
this breaks existing code which IMHO is not an option.
kind regards
angela
On 10/31/13 8:29 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
>I would object :-) and only use the following signature:
>
> boolean addEntry(Principal principal, Privilege[] privileges,
>boolean isAllow, Map<String, Value[]> mvRestrictions)
>
>Regards, toby
>
>
>
>On Thu, Oct 31, 2013 at 11:55 AM, Angela Schreiber <an...@adobe.com>
>wrote:
>> this is public API and i don't want to break existing code. originally
>> i thought that restrictions will never be multivalued, otherwise i would
>> have defined the original extension differently (right away with an
>>array).
>>
>> on the other hand i am sure that a given implementation of the OAK
>> restriction provider will be very specific on whether a given
>>restriction
>> can/must be single value or multivalued.
>>
>> and i decided not to follow your other proposal (using separate
>>interface
>> for
>> the restrictions in jackrabbit-api) and this would lead to major changes
>> throughout
>> the security api just to make it consistent... i felt that this is not
>> worth
>> the effort.
>>
>> kind regards
>> angela
>>
>> On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>
>>>Hi,
>>>
>>>> ---
>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/s
>>>>pi
>>>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>>>> +++
>>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/s
>>>>pi
>>>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>>>16:54:20 2013
>>>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>>>> }
>>>>
>>>> @Override
>>>> + public boolean addEntry(Principal principal, Privilege[]
>>>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>>>Map<String, Value[]> mvRestrictions) throws AccessControlException {
>>>> + throw new AccessControlException("Immutable ACL. Use
>>>>AccessControlManager#getPolicy or #getApplicablePolicies in order to
>>>>obtain an modifiable ACL.");
>>>> + }
>>>> +
>>>> + @Override
>>>
>>>Can't we just use the "Map<String, Value[]> mvRestrictions" argument?
>>>having both seems a bit awkward. or is there a difference if I specify
>>>a restriction with an 1 value array or a restriction with 1 value?
>>>
>>>
>>>Regards, Toby
>>
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Tobias Bocanegra <tr...@apache.org>.
sorry, I saw https://issues.apache.org/jira/browse/JCR-3641 too late.
I would object :-) and only use the following signature:
boolean addEntry(Principal principal, Privilege[] privileges,
boolean isAllow, Map<String, Value[]> mvRestrictions)
Regards, toby
On Thu, Oct 31, 2013 at 11:55 AM, Angela Schreiber <an...@adobe.com> wrote:
> this is public API and i don't want to break existing code. originally
> i thought that restrictions will never be multivalued, otherwise i would
> have defined the original extension differently (right away with an array).
>
> on the other hand i am sure that a given implementation of the OAK
> restriction provider will be very specific on whether a given restriction
> can/must be single value or multivalued.
>
> and i decided not to follow your other proposal (using separate interface
> for
> the restrictions in jackrabbit-api) and this would lead to major changes
> throughout
> the security api just to make it consistent... i felt that this is not
> worth
> the effort.
>
> kind regards
> angela
>
> On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>
>>Hi,
>>
>>> ---
>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi
>>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>>> +++
>>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi
>>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>>16:54:20 2013
>>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>>> }
>>>
>>> @Override
>>> + public boolean addEntry(Principal principal, Privilege[]
>>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>>Map<String, Value[]> mvRestrictions) throws AccessControlException {
>>> + throw new AccessControlException("Immutable ACL. Use
>>>AccessControlManager#getPolicy or #getApplicablePolicies in order to
>>>obtain an modifiable ACL.");
>>> + }
>>> +
>>> + @Override
>>
>>Can't we just use the "Map<String, Value[]> mvRestrictions" argument?
>>having both seems a bit awkward. or is there a difference if I specify
>>a restriction with an 1 value array or a restriction with 1 value?
>>
>>
>>Regards, Toby
>
Re: svn commit: r1537553 - in /jackrabbit/oak/trunk:
oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/accesscontrol/
oak-core/src/main/java/org/apache/jackrabbit/oak/spi/security/authorization/accesscontrol/
oak-core/src/test/jav...
Posted by Angela Schreiber <an...@adobe.com>.
this is public API and i don't want to break existing code. originally
i thought that restrictions will never be multivalued, otherwise i would
have defined the original extension differently (right away with an array).
on the other hand i am sure that a given implementation of the OAK
restriction provider will be very specific on whether a given restriction
can/must be single value or multivalued.
and i decided not to follow your other proposal (using separate interface
for
the restrictions in jackrabbit-api) and this would lead to major changes
throughout
the security api just to make it consistent... i felt that this is not
worth
the effort.
kind regards
angela
On 10/31/13 7:34 PM, "Tobias Bocanegra" <tr...@apache.org> wrote:
>Hi,
>
>> ---
>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi
>>/security/authorization/accesscontrol/ImmutableACL.java (original)
>> +++
>>jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi
>>/security/authorization/accesscontrol/ImmutableACL.java Thu Oct 31
>>16:54:20 2013
>> @@ -76,6 +76,11 @@ public class ImmutableACL extends Abstra
>> }
>>
>> @Override
>> + public boolean addEntry(Principal principal, Privilege[]
>>privileges, boolean isAllow, Map<String, Value> restrictions,
>>Map<String, Value[]> mvRestrictions) throws AccessControlException {
>> + throw new AccessControlException("Immutable ACL. Use
>>AccessControlManager#getPolicy or #getApplicablePolicies in order to
>>obtain an modifiable ACL.");
>> + }
>> +
>> + @Override
>
>Can't we just use the "Map<String, Value[]> mvRestrictions" argument?
>having both seems a bit awkward. or is there a difference if I specify
>a restriction with an 1 value array or a restriction with 1 value?
>
>
>Regards, Toby