[
https://issues.apache.org/jira/browse/OAK-7998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894125#comment-16894125
]
Alexander Klimetschek edited comment on OAK-7998 at 7/26/19 8:54 PM:
---------------------------------------------------------------------
[~mattvryan]
How is it possible to get the presigned URL if the upload has not completed
yet? There should be no reference in the NodeStore at all before the complete.
And after a complete, if the blob/file is empty, that is IMO a perfectly valid
situation from the blob store perspective (it doesn't know whether a client
might want to store an empty file deliberately), for which a presigned GET URL
should be generated.
We designed it explicitly so that the binary in Oak is guaranteed to be
immutable, and thus only visible after upload has completed.
was (Author: alexander.klimetschek):
[~mattvryan]
How is it possible to get the presigned URL if the upload has not completed
yet? There should be no reference in the NodeStore at all before the complete.
And after a complete, if the blob/file is empty, that is IMO a perfectly valid
situation from the blob store perspective (it doesn't know whether a client
might want to store an empty file deliberately), for which a presigned GET URL
should be generated.
> [DirectBinaryAccess] Verify that binary exists in cloud before creating
> signed download URI
> -------------------------------------------------------------------------------------------
>
> Key: OAK-7998
> URL: https://issues.apache.org/jira/browse/OAK-7998
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: blob-cloud, blob-cloud-azure
> Affects Versions: 1.10.0
> Reporter: Matt Ryan
> Assignee: Matt Ryan
> Priority: Major
> Fix For: 1.16.0, 1.10.4
>
>
> The direct binary access download logic doesn't actually verify that the
> requested blob is available in the cloud before creating the signed download
> URI. It is possible that a user could request a download URI for a blob that
> is "in the repo" but hasn't actually been uploaded yet.
> We should verify this by uploading a new blob, preventing it being uploaded
> to the cloud (retain in cache), and then request the download URI. We should
> get a null back or get some other error or exception; if we get a URI it
> would return an HTTP 404 if the blob is not actually uploaded yet (maybe this
> would also be ok).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
