[
https://issues.apache.org/jira/browse/OAK-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540398#comment-16540398
]
Alexander Klimetschek edited comment on OAK-7570 at 7/11/18 5:13 PM:
---------------------------------------------------------------------
{quote}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.
{quote}
You are right, application code could do the check itself
(session.hasPermission()). However, as we know, that isn't really done in the
case of binaries created from InputStream today (but probably should be as
well!). The general mantra with JCR is that it does access control for you, so
devs aren't really expecting to call {{session.hasPermission()}} et.al. in
their code.
And in this case here the developer will also think "I am not persisting the
session here, why should I make AC checks". Yes, it can be documented, but
experience shows this is not enough for a safe system. That's why I think it
should be forced upon clients.
The point is, even if the client could use a different path, if they do not
provide a path they have write access to, they will get an immediate
AccessDeniedException. This is not possible without a path argument (today,
without I assume bigger changes to Oaks permission model). I feel uncomfortable
taking this important security check out until there is a clear plan for a
better alternative with the same protection.
Having the client to provide the path in the API, but not leveraging it in the
implementation (in the future) seems not a problem to me.
was (Author: alexander.klimetschek):
{quote}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.
{quote}
You are right, application code could do the check itself
(session.hasPermission()). However, as we know, that isn't really done in the
case of binaries created from InputStream today. After all, the developer will
think "I am not persisting the session here". Yes, it can be documented, but
experience shows this is not enough for a safe system. That's why I think it
should be forced upon clients.
The point is, even if the client could use a different path, if they do not
provide a path they have write access to, they will get an immediate
AccessDeniedException. This is not possible without a path argument (today,
without I assume bigger changes to Oaks permission model). I feel uncomfortable
taking this important security check out until there is a clear plan for a
better alternative with the same protection.
Having the client to provide the path in the API, but not leveraging it in the
implementation (in the future) seems not a problem to me.
> [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)
