[
https://issues.apache.org/jira/browse/OAK-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150205#comment-16150205
]
Chetan Mehrotra commented on OAK-6575:
--------------------------------------
bq. This issue was to provide a external URL, not a private URL. Do you want to
add provision of a private URL here or leave it to a later issue ?
Not required for now. Lets support external url first. Objective was that with
just URI as adaptable we cannot differentiate between these 2 cases. Hence we
would need to expose a custom type. This type would also later allow us to
parametrize the URL generated if any usecases needs that.
> Provide a secure external URL to a DataStore binary.
> ----------------------------------------------------
>
> Key: OAK-6575
> URL: https://issues.apache.org/jira/browse/OAK-6575
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob, core, jcr
> Reporter: Ian Boston
> Fix For: 1.8
>
>
> Where the DataStore is a DataStore that may be accessed over an independent
> API it would be advantageous for Oak to provide a secure URL to allow direct,
> read only access to the current immutable instance of that binary. The term
> "secure" needs to be defined, but typically it would a URL that is valid for
> a appropriately short length of time to ensure that the risk of the URL being
> used by a user that it was not intended for, is minimised. It should also
> ensure that anyone in possession of the URL could not use the information in
> the url to create a valid URL or a valid URL to a different binary.
> One example of such a URL might be a AWS Signed URL as used by AWS CloudFront
> to access private content. The signed url being signed by a private key known
> only to the Oak instance and the the CloudFront or S3 instance. The signed
> url having a significantly low ttl so that a redirect by the same client
> would work.
> Oak should only emit these URLs to sessions that could otherwise read the
> binary directly from Oak, and Oak should be in complete control of the nature
> of the url and the security mechanisms applied to the URL.
> The viability of the approach has been investigated showing that given a JCR
> Binary it is possible to get the Oak Blob Content Identifier using
> ValueImpl.getBlob((Value)jcrBinary).getContentIentifier() and form there,
> knowing the way in which the DataStore implementation transforms that into a
> pointer into the datastore implementation form a URL to be made secure.
> To achieve the above, internal implementation details specific to the Oak
> DataStore implementation are required, hence this request to implement as a
> part of Oak rather than to reverse engineer in some external project.
> Since API changes are often significant using the Sling AdapaterFactory
> approach would allow a ServletFilter to selectively use the URL in a
> redirect, avoiding any new API methods to existing Oak APIs. A new interface
> might be required, in the example below that interface is SignedBinaryURL.
> {code}
> public void doFilter(ServletRequest servletRequest, ServletResponse
> servletResponse, FilterChain filterChain) throws IOException,
> ServletException {
> if ( servletRequest instanceof SlingHttpServletRequest &&
> servletResponse instanceof SlingHttpServletResponse) {
> if ("GET".equals(((SlingHttpServletRequest)
> servletRequest).getMethod())){
> Resource resource = ((SlingHttpServletRequest)
> servletRequest).getResource();
> SignedBinaryURL url = resource.adaptTo(SignedBinaryURL.class);
> if (url != null) {
> ((SlingHttpServletResponse)
> servletResponse).sendRedirect(url.getURL());
> return;
> }
> }
> }
> filterChain.doFilter(servletRequest, servletResponse);
> }
> {code}
> If the AdapterFactory to go from Binary to SingedBinaryURL is not present
> then url will always be null, and no-op. If it is present, and Oak decides no
> URL is appropriate, then no-op.
> Only if the Oak DS implementation being used supports the external URL and
> Oak decides it is appropriate, will a url be available and a redirect
> performed.
> I have used AWS S3 URLs as an example, however the approach should be
> applicable (and pluggable) to most REST based APIs to private binary content.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
