You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Nitin Gupta (JIRA)" <ji...@apache.org> on 2019/08/16 02:59:00 UTC

[jira] [Closed] (OAK-8520) [Direct Binary Access] Avoid overwriting existing binaries via direct binary upload

     [ https://issues.apache.org/jira/browse/OAK-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nitin Gupta closed OAK-8520.
----------------------------

> [Direct Binary Access] Avoid overwriting existing binaries via direct binary upload
> -----------------------------------------------------------------------------------
>
>                 Key: OAK-8520
>                 URL: https://issues.apache.org/jira/browse/OAK-8520
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: blob-cloud, blob-cloud-azure, blob-plugins
>            Reporter: Matt Ryan
>            Assignee: Matt Ryan
>            Priority: Major
>             Fix For: 1.18.0, 1.10.4
>
>
> Since direct binary upload generates a unique blob ID for each upload, it is generally impossible to overwrite any existing binary.  However, if a client issues the {{completeBinaryUpload()}} call more than one time with the same upload token, it is possible to overwrite an existing binary.
> One use case where this can happen is if a client call to complete the upload times out.  Lacking a successful return a client could assume that it needs to repeat the call to complete the upload.  If the binary was already uploaded before, the subsequent call to complete the upload would have the effect of overwriting the binary with new content generated from any uncommitted uploaded blocks.  In practice usually there are no uncommitted blocks so this generates a zero-length binary.
> There may be a use case for a zero-length binary so simply failing in such a case is not sufficient.
> One easy way to handle this would be to simply check for the existence of the binary before completing the upload.  This would have the effect of making uploaded binaries un-modifiable by the client.  In such a case the implementation could throw an exception indicating that the binary already exists and cannot be written again.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)