Hi Ian
On 04/05/16 18:37, "Ian Boston" <i...@tfd.co.uk> wrote:
>[...] The locations will certainly probably leak
>outside the context of an Oak session so the API contract should make it
>clear that the code using a direct location needs to behave responsibly.
See my reply to Chetan, who was referring to
SlingRepository.loginAdministrative
which always had a pretty clear API contract wrt responsible usage.
As a matter of fact (and I guess you are aware of this) it turned into a
total nightmare with developers using it just everywhere, ignoring not
only
the API contract but also all concerns raised for years. This can even
been seen in Apache Sling code base itself.
So, I am quite pessimistic about responsible usage and API contract
and definitely prefer an API implementation that effectively enforces
the contract.
Vulnerable by design is IMHO a bad guideline for introducing new APIs.
>From my experiences they backfire usually sooner than later and need
to be abandoned again... so, I'd rather aim for a properly secured
solution right from the beginning.
Kind regards
Angela
>
>Best Regards
>Ian
>
>
>On 3 May 2016 at 15:36, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote:
>
>> Hi Team,
>>
>> For OAK-1963 we need to allow access to actaul Blob location say in form
>> File instance or S3 object id etc. This access is need to perform
>>optimized
>> IO operation around binary object e.g.
>>
>> 1. The File object can be used to spool the file content with zero copy
>> using NIO by accessing the File Channel directly [1]
>>
>> 2. Client code can efficiently replicate a binary stored in S3 by having
>> direct access to S3 object using copy operation
>>
>> To allow such access we would need a new API in the form of
>> AdaptableBinary.
>>
>> API
>> ===
>>
>> public interface AdaptableBinary {
>>
>> /**
>> * Adapts the binary to another type like File, URL etc
>> *
>> * @param <AdapterType> The generic type to which this binary is
>> adapted
>> * to
>> * @param type The Class object of the target type, such as
>> * <code>File.class</code>
>> * @return The adapter target or <code>null</code> if the binary
>>cannot
>> * adapt to the requested type
>> */
>> <AdapterType> AdapterType adaptTo(Class<AdapterType> type);
>> }
>>
>> Usage
>> =====
>>
>> Binary binProp = node.getProperty("jcr:data").getBinary();
>>
>> //Check if Binary is of type AdaptableBinary
>> if (binProp instanceof AdaptableBinary){
>> AdaptableBinary adaptableBinary = (AdaptableBinary) binProp;
>>
>> //Adapt it to File instance
>> File file = adaptableBinary.adaptTo(File.class);
>> }
>>
>>
>>
>> The Binary instance returned by Oak
>> i.e. org.apache.jackrabbit.oak.plugins.value.BinaryImpl would then
>> implement this interface and calling code can then check the type and
>>cast
>> it and then adapt it
>>
>> Key Points
>> ========
>>
>> 1. Depending on backing BlobStore the binary can be adapted to various
>> types. For FileDataStore it can be adapted to File. For S3DataStore it
>>can
>> either be adapted to URL or some S3DataStore specific type.
>>
>> 2. Security - Thomas suggested that for better security the ability to
>> adapt should be restricted based on session permissions. So if the user
>>has
>> required permission then only adaptation would work otherwise null
>>would be
>> returned.
>>
>> 3. Adaptation proposal is based on Sling Adaptable [2]
>>
>> 4. This API is for now exposed only at JCR level. Not sure should we do
>>it
>> at Oak level as Blob instance are currently not bound to any session. So
>> proposal is to place this in 'org.apache.jackrabbit.oak.api' package
>>
>> Kindly provide your feedback! Also any suggestion/guidance around how
>>the
>> access control be implemented
>>
>> Chetan Mehrotra
>> [1] http://www.ibm.com/developerworks/library/j-zerocopy/
>> [2]
>>
>>
>>https://sling.apache.org/apidocs/sling5/org/apache/sling/api/adapter/Adap
>>table.html
>>
