On 10 May 2016 at 15:02, Angela Schreiber <anch...@adobe.com> wrote:
> 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.
>
Fair enough, provided there is a solution that addresses the issue Chetan
is trying to address.
The alternative, for some applications, seems to store the binary data
outside Oak, which defeats the purpose completely.
I don't have a perfect handle on the issue he is trying to address or what
would be an acceptable solution, but I suspect the only solution that is
not vulnerable by design will a solution that abstracts all the required
functionality behind an Oak API (ie no S3Object, File object or anything
that could leak) and then provide all the required functionality with an
acceptable level of performance in the implementation. That is doable, but
a lot more work.
Best Regards
Ian
>
> 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
> >>
>
>
