emcecs / ecs-object-client-dotnet Goto Github PK

Add extension method into ECSS3Client to provide paging through buckets in method ListBuckets()

There are 22 ASCII characters that will work with the JAVA SDK but not with the .NET SDK when being set as as part of the metadata keys.
ECS returns Http code 403 with message:

“The request signature we calculated does not match the signature you provided. Check your Secret Access Key and signing method. For more information, see REST Authentication and SOAP Authentication for details.”

Analysis

When the SDK signs the request that will be verified on the server, it orders the keys (headers) using "StringComparer.OrdinalIgnoreCase". But, on the server, the JAVA version generates a different signature, thus, it does not match and throws a 403 Signature Does not match

Method: static string BuildCanonicalizedHeaders(IDictionary<string, string> headers)

Class:
S3SignerECS

Version: v1.0.1

Repro steps

You can find attached two unit test projects showcasing the bug, one for NET and one for JAVA.

If you run the same example, you will notice with the JAVA SDK, you won't get the Signature match error. Most likely because the JAVA SDK uses the TreeMap class that performs a natural ordering.

dotnetUnderscoreECSTest.zip

JavaUnderscoreECSTest2.zip

Solution

We'd need a fix on the .NET SDK that signs the request same way the JAVA one does.