[
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
(v7.6.3#76005)
