Spaces PHP SDK Changing ACL Error when Filepath or File contains symbols (like an @ (at))

July 12, 2019 266 views
DigitalOcean

I’m using the PHP AWS SDK, as suggested by a mod. (here)

I’m using the putObjectAcl function from the AWS PHP SDK. And when I input a Filepath or Filename, that contains symbols like @ (at) the function returns an Exception. I opened an Issue Ticket on the repo of the PHP AWS SDK addressing this issue, to make sure, that the SDK itself isn’t the problem. (The Issue Ticket)

And the answer from a contributor concludes that the problem has to be on Digitaloceans end. In more detail, that Digitalcoean isn’t encoding the URL again, thus the File cant be found.

Here are the technical informations:

root@debian:~/test2# php setPublic.php
PHP Fatal error:  Uncaught exception 'Aws\S3\Exception\S3Exception' with message 'Error executing "PutObjectAcl" on "https://SPACE_NAME.fra1.digitaloceanspaces.com/%40acex/mod.cpp?acl"; AWS HTTP error: Client error: `PUT https://SPACE_NAME.fra1.digitaloceanspaces.com/%40acex/mod.cpp?acl` resulted in a `403 Forbidden` response:
<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code><RequestId>tx000000000000009ee57cd-005d26 (truncated...)
 SignatureDoesNotMatch (client):  - <?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code><RequestId>tx000000000000009ee57cd-005d2636b1-1c0f65-fra1a</RequestId><HostId>1c0f65-fra1a-fra1</HostId></Error>'

GuzzleHttp\Exception\ClientException: Client error: `PUT https://SPACE_NAME.fra1.digitaloceanspaces.com/%40acex/mod.cpp?acl` resulted in a `403 Forbidden` response:
<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code><RequestId>tx000000000000009ee57cd-005d26 (truncated...)
 in /root/test2/ven in /root/test2/vendor/aws/aws-sdk-php/src/WrappedHttpHandler.php on line 195

Steps to reproduce

<?php
require 'vendor/autoload.php';
use Aws\S3\S3Client;

$key = "PRIVATE_KEY";
$secret = "PRIVATE_SECRET";

$space = "SPACE_NAME";
$region = "REGION";
$host = "digitaloceanspaces.com";
$endpoint = "https://".$space.".".$region.".".$host;


$client = Aws\S3\S3Client::factory(array(
    'region' => $region,
    'version' => 'latest',
    'endpoint' => $endpoint,
    'credentials' => array(
              'key'    => $key,
              'secret' => $secret,
          ),
    'bucket_endpoint' => true,
    'signature_version' => 'v4-unsigned-body'
  ));

  $aclHeader = ["ACL" => "public-read"];
  $acl = array_merge(array("Bucket" => $space, "Key" => '@acex/mod.cpp'), $aclHeader);

  $client->putObjectAcl($acl);
2 Answers

Hey there,

One thing I recommend trying: explicitly use v2 signatures, as the encoding rules differ from v4 signatures. I’ve seen success with that in the past.

Should you continue seeing issues, we’ll need to dig in further as there is a lot of variation from SDK to SDK. Could you capture the full request + response headers that are being sent to the Spaces API by your script so we can evaluate them? (you should redact your values of DO_ACCESS_KEY_ID and DO_SPACE if you do post it publically)

With the headers, we’ll be able to tell if this is an issue with encoding on the client SDK end or on our end with Spaces resolving the request.

I personally recommend writing these into a ticket: https://do.co/new-ticket where our Developer Support team can assist (just reference this community post, if you’d like, you can even ask for me). Or you can include the outputs here, just remember to redact the above.

Regards,
Ethan F
Storage Developer Support Engineer II - DigitalOcean

@TAINCER Did you manage to sort out the issue? I find many of these questions, with the answer above, but no final resolution. If you found a working workaround or solution, please share.

My related question: https://www.digitalocean.com/community/questions/signaturedoesnotmatch-error-with-special-characters-in-the-file-name

Have another answer? Share your knowledge.