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

Jim Sermersheim updated JCLOUDS-1595:
-------------------------------------
    Description: 
org.jclouds.s3.filters.Aws4SignerBase#getCanonicalizedQueryString should leave 
the '/' char unescaped when it is being used by 
org.jclouds.s3.filters.Aws4SignerBase#createStringToSign

As it is, it's escaping the '/' char in the query string, and this is not 
consistent with the actual query string that is used in the URL when making the 
HTTP request (the '/' is unescaped in that case).

This is currently causing a bug when jclouds is used to list with a prefix 
against NetApp's ONTAP S3 server (version 9.10.1). The calculation of the S3 V4 
signature differs between JClouds and the NetApp because the NetApp is 
calculating the signature witn unescaped slashes (which is what the client sent 
in the URL)

For reference, the error coming back from the NetApp ONTAP is a 403 with the 
message: "The request signature we calculated does not match the signature you 
provided. Check your key and signing method."

Other S3 servers must be more lenient in this regard, or perhaps don't validate 
the signature.

  was:
When org.jclouds.s3.options.ListBucketOptions calls {{queryParameters.put}} any 
string values should be url encoded.

This is currently causing a bug when jclouds is used to list with a prefix 
against NetApp's ONTAP S3 server (version 9.10.1). The calculation of the S3 V4 
signature differs between JClouds and the NetApp because the NetApp is 
calculating it with escaped slashes (in the observed case, the delimiter was 
"/" and the prefix ended with a "/". Both need to be escaped as %2F prior to 
building the Authorization header.

For reference, the error coming back from the NetApp ONTAP is a 403 with the 
message: "The request signature we calculated does not match the signature you 
provided. Check your key and signing method."


> Aws4SignerBase.getCanonicalizedQueryString should not escape the slash char
> ---------------------------------------------------------------------------
>
>                 Key: JCLOUDS-1595
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1595
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-blobstore
>    Affects Versions: 2.4.0
>            Reporter: Jim Sermersheim
>            Priority: Minor
>              Labels: s3
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> org.jclouds.s3.filters.Aws4SignerBase#getCanonicalizedQueryString should 
> leave the '/' char unescaped when it is being used by 
> org.jclouds.s3.filters.Aws4SignerBase#createStringToSign
> As it is, it's escaping the '/' char in the query string, and this is not 
> consistent with the actual query string that is used in the URL when making 
> the HTTP request (the '/' is unescaped in that case).
> This is currently causing a bug when jclouds is used to list with a prefix 
> against NetApp's ONTAP S3 server (version 9.10.1). The calculation of the S3 
> V4 signature differs between JClouds and the NetApp because the NetApp is 
> calculating the signature witn unescaped slashes (which is what the client 
> sent in the URL)
> For reference, the error coming back from the NetApp ONTAP is a 403 with the 
> message: "The request signature we calculated does not match the signature 
> you provided. Check your key and signing method."
> Other S3 servers must be more lenient in this regard, or perhaps don't 
> validate the signature.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to