[jira] [Created] (JCLOUDS-1571) Unable to provide custom signed headers using BlobRequestSigner#signPutBlob

["Filip Panovski (Jira)" <ji...@apache.org>]

Filip Panovski created JCLOUDS-1571:
---------------------------------------

             Summary: Unable to provide custom signed headers using BlobRequestSigner#signPutBlob
                 Key: JCLOUDS-1571
                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1571
             Project: jclouds
          Issue Type: Bug
          Components: jclouds-blobstore, jclouds-core
    Affects Versions: 2.3.0
         Environment: Debian
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

            Reporter: Filip Panovski


(Disclaimer: I'm not 100% sure whether this is a bug report or a feature request, as I've found only scant information available)

We have the use case where we wish to provide a signed aws-s3 {{PUT}} URL to a browser client which will be used to process a file upload (non-chunked, single URL). We are using version {{2.3.0}} (the latest public release).

 The {{jclouds}} API has support for this via {{BlobStoreContext#getSigner}} , i.e. {{BlobRequestSigner#signPutBlob(String containerName, Blob blob, long timeInSeconds)}}.

 However, there seems to be no support for signing custom headers as part of the URL.

 The relevant AWS Documentation (link [here|https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html]) states that:
{code:java}
For added security, you should sign all the request headers that you plan to include in your request.
{code}
I dug around the {{jclouds-core}} code and saw that, for pre-signed {{PUT}} requests, a {{PhantomPayload}} is used which appears, for all intents and purposes, as a real payload with checksum and content-length.

However, although this information is available at the time of signing, the only headers which are part of the signed headers are those which are either specifically annotated as such (e.g.: {{org.jclouds.s3.S3Client#putObject}}, which contains {{@Headers(keys = EXPECT, values = "100-continue"}}) or are otherwise part of normal request flow depending on media type (i.e. {{content-type}}, {{accept}}).

The way I access the API is as follows:
{code:java}
@Override
public URI getPreSignedPutUrl(final String blobId, final long contentLength, final String checksum,
        final String mediaType) {
    BlobStoreContext context = blobStoreContextProvider.getBlobStoreContext();
    BlobRequestSigner signer = context.getSigner();
    Blob expectedBlob = context.getBlobStore().blobBuilder(blobId)
            .forSigning()
            .contentType(mediaType)
            .contentMD5(HashCode.fromString(checksum))
            .contentLength(contentLength)
            .build();
    HttpRequest request = signer.signPutBlob(this.bucket.getName(), expectedBlob, 60);
    return request.getEndpoint();{code}
What I _expected_ to happen was:
 # A pre-signed URL is created with the blob I pass it.
 # The blob's content-md5 and content-length values are passed through as part of the signed headers.
 # The pre-signed URL includes these values so that only a specific file (or something that has exactly that checksum and content length) can be uploaded to said URL.

What _did_ happen was:
 # A pre-signed URL is created with the blob I pass it.
 # {{RestAnnotationProcessor}} and the default {{S3Client}} API both seem to not take any of the blob metadata into account
 # The pre-signed URL includes only the {{host}} header as a signed header.

As a result, I can upload any file I wish to the pre-signed {{PUT}} URL, not just the one that I specifically intended, although metadata like content checksum and length is available and could also be signed within the request.

For what it's worth, I did try to extend the existing {{BlogRequestSigner}} to include {{PutOptions}} (which have an effect on signed headers, as far as I can tell, see: {{[RestAnnotationProcessor#apply:282|https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/rest/internal/RestAnnotationProcessor.java#L282]}}), but got lots of Guice binding errors that I was unable to resolve. I am relatively new to Guice, so that might have been user error - as the documentation is lacking though, I'm unsure if that's the preferred way.

Lastly, https://issues.apache.org/jira/browse/JCLOUDS-1161 exists which seems loosely related to my issue. As I understand it though, the "workaround" described therein should no longer be necessary (since V4 is automatically used for {{aws-s3}} since ~{{2.2.0}}) and it does not help in my case either.


Is the current behaviour, as described above, correct? Is the lack of a support for additional signed headers intentional? Is there another way that I'm not quite seeing?

Any feedback would be greatly appreciated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)