jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Ryan (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-7637) [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?
Date Wed, 18 Jul 2018 02:28:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16547218#comment-16547218
] 

Matt Ryan edited comment on OAK-7637 at 7/18/18 2:27 AM:
---------------------------------------------------------

[~reschke]:
{quote}The ability to modify Content-Type as request parameter sounds like a security issue
waiting to happen.
{quote}
Can you please give an example of your concerns in this regard?

Keep in mind that only an authenticated JCR session will be able to actually make this happen. 
This action doesn't set the stored content type of the binary, just the value that will be
used in the {{Content-Type}} header of the response.  This is set in a signed URI that cannot
be changed by the end client that is issuing the request to the URI.
{quote}If the stores support setting the Content-Type upon creation, why not use it?
{quote}
Since both S3 and Azure will allow it, it could be possible with {{S3DataStore}} and {{AzureDataStore}}, but
other data stores (like {{FileDataStore}}) would not be able to support storing metadata alongside
the binary - at least not without significant changes.  Making a change to support the storing
of the content type in the data store would require changing data store implementations as
well as the {{DataStore}} API.  I think that discussion is outside the scope of this feature.


was (Author: mattvryan):
[~reschke]:
{quote}The ability to modify Content-Type as request parameter sounds like a security issue
waiting to happen.
{quote}
Can you please give an example of your concerns in this regard?

Keep in mind that only an authenticated JCR session will be able to actually make this happen. 
This action doesn't set the stored content type of the binary, just the value that will be
used in the {{Content-Type}} header of the response.  This is set in a signed URI that cannot
be changed by the end client that is issuing the request to the URI.
{quote}If the stores support setting the Content-Type upon creation, why not use it?
{quote}
{{S3DataStore}} and {{AzureDataStore}} both will allow it, but other data stores (like {{FileDataStore}})
do not.  Making a change to support the storing of the content type in the data store would
require changing data store implementations as well as the {{DataStore}} API.  I think that
discussion is outside the scope of this feature.

> [DirectBinaryAccess][DISCUSS] How to set response headers for direct download URIs?
> -----------------------------------------------------------------------------------
>
>                 Key: OAK-7637
>                 URL: https://issues.apache.org/jira/browse/OAK-7637
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: blob-cloud, blob-cloud-azure
>            Reporter: Matt Ryan
>            Assignee: Matt Ryan
>            Priority: Major
>
> There are at least three headers that need to be set in responses to direct GET URIs:
>  * {{Content-Type}}
>  * {{Content-Disposition}}
>  * {{Cache-Control}}
> In order for the URIs to behave as expected when directly reading a binary, these headers
should be set.
> h3. Content-Type
> Binary data is stored in an Oak repository as raw bytes only, with no associated content
type.  When a client obtains a download URI and issues a request to that URI, the resulting
response should have the {{Content-Type}} header set so that the binary data will be interpreted
properly by the client.
> h3. Content-Disposition
> Binary data is stored in an Oak repository using a system-generated identifier for the
blob, which is not a user-friendly name for the content being represented.  When a client
obtains a download URI and issues a request to that URI, the resulting response should have
the {{Content-Disposition}} header set to a user-friendly name for that binary.  For example,
a PDF document stored in the repository as "TeamGoals.pdf" would have a completely different
blob name, and the generated URI to read that PDF directly from storage would also have that
unhelpful name.  If the {{Content-Disposition}} header is set, then an end user trying to
save the PDF from a web page link would save it using the name returned in the {{Content-Disposition}}
header rather than the blob name.
> h3. Cache-Control
> Since binary data in an Oak repository is essentially not changed after it is created,
it is cacheable, so the {{Cache-Control}} header should be set to allow the binary to be cached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message