Using a bucket name with dots in it (eg foo.bar.bucket) results in an error "There was a problem using S3".

Comments

Dots in bucket names is ok as per the example provided. See http://docs.amazonwebservices.com/AmazonS3/latest/dev/BucketRestrictions...

Status:Active» Closed (duplicate)

Status:Closed (duplicate)» Active

I don't think that this is a duplicate of #1676988 since I get this error regardless of how "Determine which Certificate Authority file to use." is checked.

i have two buckets, one with dots, the other without. Everything else exactly the same. I can enter the one without dots just fine. The one with dots, "There was a problem using S3"

Also, I am not using MAMP, in fact everything works perfectly except I can't use the bucket I want to as a CNAME because there are dots in the name of the bucket.

I believe that this thread on AWS' forum is relevant. This comment summarizes it well.

I exposed the error by doing this in amazons3.module:

    catch(Exception $e) {
    $str = $e->getMessage();
      form_set_error('amazons3_bucket', t("There was a problem using  S3. $str "));
    }

Which revealed this error when I would use the bucket with dots in it:
cURL resource: Resource id #10; cURL error: SSL: certificate subject name '*.s3.amazonaws.com' does not match target host name '[REDACTED].com.s3.amazonaws.com

As a fix, as recommended in the AWS Forum thread, I did this to ../libraries/awssdk/services/s3.class.php:

#       public $path_style = false;
        public $path_style = true;

Which fixes it for me.

I'm editing this reply because it occurred to me that it is true that on the front page of the module, there is a notice about SSL issues, and that's what I first looked at, and this is an SSL issue. It's just that the wording of the error and the link attached to it is somewhat misleading (as far as I understand it). In this case, it's not that my server is missing CA cert files, it's that the dots in foo.bar.s3.amazonaws.com does not match the wildcard of the S3 cert *.s3.amazonaws.com

Title:Error with bucket names containing dots (.)Error with bucket names containing dots (.) over SSL
Status:Active» Closed (won't fix)

Thanks for looking into this.

I currently use a bucket with dots in and I'm not having any issues. Reading the thread it seems that either your curl library may not have the correct certificate setup or you're trying to deliver over SSL, which according to https://forums.aws.amazon.com/thread.jspa?threadID=69108&start=0&tstart=... is not currently possible.

Doesn't look like there's anything we can do on this end, so I'll leave a note on the project page.

How would I go about determining if curl is trying to deliver over SSL? I agree, that is likely part of the problem, but I don't see where to change that.

Status:Closed (won't fix)» Active

The fix in #4 for worked for me. Before the fix, I would get this error:

cURL_Exception: cURL resource: Resource id #203; cURL error: SSL peer certificate or SSH remote key was not OK (cURL error code 51). See http://curl.haxx.se/libcurl/c/libcurl-errors.html for an explanation of error codes. in RequestCore->send_request() (line 830 of sites/all/libraries/awssdk/lib/requestcore/requestcore.class.php).

This is using curl version 7.28.1 compiled with SSL support (OpenSSL/1.0.1c).

Reading the thread at https://forums.aws.amazon.com/thread.jspa?threadID=69108&start=25&tstart=0 it seems the issue is that newer version of openssl implement stricter SSL CN matching, which leads to the above error.

This is going to cause problems for users as their systems are upgraded, as previously where AmazonS3.module was working fine they will now get an error. In the absence of Amazon solving this from their side, the only permanent solution seems to be not using dots in the bucket name. Or...

What about setting the <?php public $path_style = true; ?> variable by using an extra setting on the admin/config/media/amazons3 page (i.e. using a drupal variable)? That would mean patching s3.class.php to use the drupal variable. There is already a drush make file for awssdk, so it would be simple to add a patch to the drush make file.

My host (Omega8) recently upgraded OpenSSL, and this issue bit me badly. So I have been plugging away at it.

It seems that part of the difficulty in fixing this issue is that the awssdk module has a make file inside it. So, I propose to "fix" the problem in two steps:

  1. Write a patch for the actual Amazon Web Services SDK code, as described in #4 and #7, above. (Patch #1.)
  2. Write a patch for the awssdk module that removes the make file entirely. (Patch #2.)

The above solution makes each site builder responsible for getting the awssdk library and putting it where it needs to go, but we do that already. When I specify the awssdk library within my own make file, I'll simply include a reference to the patch in step #1, and I'm ready to go.

It's strange to have patches to another module in this issue queue, but... it "fixes" the problem presented here, and may be helpful to someone else. I also doubt that the awssdk module maintainer would be open to receiving these patches on a permanent basis.

Just a point of clarification, and I'll be done here. By default, the primary make file that I create overrides the make file located in the awssdk module (take a look at this comment to see that). Consequently, the second patch in comment #8 is unnecessary.

It turns out that if you read the rest of the way down the thread, you'll find that the behavior of the overrides is dependent on the version of drush that you have. So the best thing to do is to simply remove the make file from awssdk. That's what I'd recommend.

This doesn't require a patch to the SDK: there's a function on the AmazonS3 class called enable_path_style() which will set the $path_style variable to true. Here's a patch that calls enable_path_style() every time an AmazonS3 object is created.

Issue summary:View changes
StatusFileSize
new2.66 KB

I also add region settings for fix code 301 error.

#11 works for me (Using the EU region), thanks a lot @jamesliu78

Status:Active» Needs review

There's a subtle but significant problem with the patch in #11. The call to libraries_load('awssdk') is not being used properly, and it's misuse causes the surrounding if test to be totally worthless. libraries_load() returns an array with tons of data about the library, even if said library is not installed (or improperly installed). What that line should look like is this:

<?php
$library
= libraries_load('awssdk');
if (!
$library['loaded']) {
?>

I wish I knew the right away to offer this change as a patch file. Would it be correct to attach an edited version of jamesliu78's patch, or an "interdiff" (which I've heard of, but have no idea how to create), or something else?

Fixed issue from #14 and also fixed a typo in the variable name (amazones3_region vs amazons3_region)

Status:Needs review» Fixed

This is fixed in SDK 1.6.2, the path generated is slightly different.

Status:Fixed» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.