Marcel Reutegger commented on OAK-7570:

bq. in the NodeStores, BlobStores and DataStores that choose to provide this 

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 

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 

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

Reply via email to