jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-7589) [DirectBinaryAccess][DISCUSS] Client facing API
Date Tue, 03 Jul 2018 11:50:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531244#comment-16531244

Marcel Reutegger commented on OAK-7589:

Regarding the authorization aspect of the feature. As mentioned by Alex in OAK-7570:

bq. With a very limited view on the current patch and after having a chat with Michael Dürig
I think this part should be taken on as a dedicated issue not as a side note on an unrelated
patch. The current behavior even if problematic has been there since the beginning and it
deserves a proper analysis and fix, there may be other entry points into binary creation and
all of them must be protected.

I also suggest to look at the authorization in a separate issue with the goal to find a solution
that works for existing methods like {{ValueFactory.createBinary(InputStream)}}. See OAK-7602.

> [DirectBinaryAccess][DISCUSS] Client facing API
> -----------------------------------------------
>                 Key: OAK-7589
>                 URL: https://issues.apache.org/jira/browse/OAK-7589
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>            Reporter: Matt Ryan
>            Assignee: Matt Ryan
>            Priority: Major
> From a discussion w/ [~mreutegg]:  Suggested that we move the API changes out of oak-jcr
(i.e. org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryProvider and org.apache.jackrabbit.oak.jcr.api.binary.HttpBinaryDownload
to a different package to avoid unnecessary API changes to oak-jcr.
> This issue should also be used to discuss how exactly the client facing API is designed.

This message was sent by Atlassian JIRA

View raw message