[
https://issues.apache.org/jira/browse/OAK-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539727#comment-16539727
]
Marcel Reutegger commented on OAK-7570:
---------------------------------------
bq. in the NodeStores, BlobStores and DataStores that choose to provide this
implementation
While this is true for the BlobStore and the DataStore, it is not actually true
for the NodeStore implementation. In the initial PR the NodeStore must provide
an implementation for this feature even if the BlobStore does not implement
HttpBlobProvider.
bq. What do you think is the current javadoc implying that is a problem?
I was reading Michael's comment as a reply to "We only want to prevent a user
who cannot write a binary _anywhere_ from being able to upload in the first
place". If the goal is to prevent an upload for a read-only session, then you
don't need the path as an argument.
bq. This is a proper permission check using Oak's existing access control
mechanisms... checking if the user can set the binary property. We are not
inventing anything new here.
But the path parameter also doesn't add anything useful to the API. The current
API already allows a client to perform this check and then decide to proceed
with requesting upload URLs. In my view, combining them in a single call gives
a false sense of security because client code is free to use whatever path it
wants.
bq. We simply replicate something that was previously a single request (upload
binary) and single JCR session operation (set binary property + save), into two
separate requests (initiate + complete). Where the initiate step must fail
already if the permission is not right.
Please note, the single request case is not necessarily a single JCR session
operation. There's a deprecated {{Node.setProperty(String, InputStream)}}, but
the recommended approach is via {{ValueFactory.createBinary(InputStream)}},
where Oak currently does not have a permission check.
bq. However, if we turn it around and start with no path argument and no check,
but later want to introduce it, we would have to change the API and force all
clients to change.
What I would keep is the declaration of {{AccessDeniedException}}. This already
indicates now that the implementation may perform a permission check.
> [DirectBinaryAccess][DISCUSS] How to access HttpBlobProvider from oak-jcr
> -------------------------------------------------------------------------
>
> Key: OAK-7570
> URL: https://issues.apache.org/jira/browse/OAK-7570
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: jcr
> Reporter: Matt Ryan
> Assignee: Matt Ryan
> Priority: Major
>
> Open discussion related to OAK-7569:
> The [original pull request|https://github.com/apache/jackrabbit-oak/pull/88]
> proposes changes to oak-api, oak-segment-tar, oak-store-document, oak-core,
> and oak-jcr as well as oak-blob-plugins, oak-blob-cloud, and oak-blob-azure.
> Would it be possible / better to keep the changes local to the oak-blob-*
> bundles and avoid making changes throughout the stack?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
