SignatureDoesNotMatch error with special characters in the file name

November 6, 2019 384 views
DigitalOcean Spaces

When adding a special character to a file name, the file upload results into an error. I’m using the Spaces-API PHP library with the latest AWS S3 client, as recommended in the DigitalOcean documentation.

Example:
image.png uploads fine
image@2x.png results in error

The error:

Exception has occurred.
GuzzleHttp\Exception\ClientException: Client error: `PUT https://foo.ams3.digitaloceanspaces.com/staging/test/s/Test2%40x5dc343e17c8838.99908039.png` resulted in a `403 Forbidden` response:
<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code><RequestId>tx00000000000 (truncated...)

Example code to reproduce the error:

// Connect
$space = new SpacesConnect($key, $secret, $space_name, $region);

// Generate file id
$file_id = uniqid('', true);

// File name
$filename  = $file_id . '@2x.png';

// Path to file
$path_file = 'test/' . $filename;

// Upload source file to CDN
$space->UploadFile($data, 'public', $path_file, '', $mime);
2 Answers

Solved the issue by patching up the SDK: https://github.com/MelvinRook/Spaces-API

Hello, @MelvinRook

I believe this was discussed in https://www.digitalocean.com/community/questions/spaces-php-sdk-changing-acl-error-when-filepath-or-file-contains-symbols-like-an-at

You can check the reply from @efox

Hope this helps!

Regards,
Alex

  • Thanks. I’ve seen that answer copy/pasted in a few questions indeed. Appreciate the share, missed this particular question in my search.

    Few points:

    • v2 signatures are end of life (although AWS extended the support till June 2020
    • v2 signatures seems to be already unsupported by DigitalOcean, as I receive a 403 authorization error when using them
    • The v4 problem still remains on the end of DigitalOcean, as described in this ticket on the library: https://github.com/aws/aws-sdk-php/issues/1846#issuecomment-510688803

    “Since DigitalOcean Spaces is not an Amazon product I cannot deterministically say what exactly is causing this behavior. That being said, I suspect it is because DigitalOcean Spaces does not appear to perform URL encoding on object URLs in the same way Amazon S3 does, so when the AWS SDK for PHP (or, more specifically, the GuzzleHttp package used by the SDK) url-encodes the request path before sending out the request DigitalOcean does not url-decode the request path which results in a signature mismatch between the canonical URI (php/1846/@atsign/test) present in the request signature and the object being requested (php/1846/%40atsign/test).”

Have another answer? Share your knowledge.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!