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-7570) [DirectBinaryAccess][DISCUSS] How to access HttpBlobProvider from oak-jcr
Date Wed, 11 Jul 2018 08:37:00 GMT

    [ 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

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

View raw message