jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject 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...
Date Thu, 31 Oct 2013 22:59:22 GMT
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" <tripod@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 <anchela@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" <tripod@apache.org> wrote:
>>
>>>On Thu, Oct 31, 2013 at 2:27 PM, Angela Schreiber <anchela@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" <tripod@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 <anchela@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" <tripod@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
>>>>>>
>>>>
>>


Mime
View raw message