Amazon S3, AWS SDK, Zencoder & Private URLS

Thank you Jorrit!

We are perfectly happy sticking with download only w/ HTML5 players... We have entered the distribution domain in the CNAME / CDN field- What else do you feel would we need to do to get the Video module to use CloudFront?

Thank you!

- Josh

Update-

We have set nearly everything we can find between AWS and Drupal to push things toward using CloudFront for content access. We have only one distribution, and it is download style. We have added CNAMEs, removed CNAMES, done everything we could, but alas, Video pulls direct from the S3 bucket.

Additionally- While the bucket ACLs only allow Zencoder and my AWS API Identity, all of the media is being transferred from Zendcoder and set to public read / EVERYONE has Open/Download permissions- this is a bit of an issue when the intention is to use signed URLs. The signed URLs work, but one can just delete the signature and the video plays. Doh!

I attempted switching the AWS ACL variable from PUBLIC to PRIVATE, but it does not seem to matter. Perhaps Zencoder is setting the ACL on the file when it uploads it?

BTW- Everything works perfectly if we go through and modify the ACLs on every file manually, but life it too short for that.

Ideas?

This is a workaround to what seems like Zencoder posting with wrong ACLs... A bucket policy to prevent hotlinking. Uploads and transcodes work fine as long as Zencoder is granted at the ACL level (not in a policy).

{
 "Version":"2008-10-17",
 "Id":"",
 "Statement":[{
   "Sid":"Allow my domains",
   "Effect":"Allow",
   "Principal":{
    "AWS":"*"
   },
   "Action":"s3:GetObject",
   "Resource":"arn:aws:s3:::YOUR-BUCKET-NAME/*",
   "Condition":{
    "StringLike":{
     "aws:Referer":["http://your-domain-name/*",
      "http://www.your-domain-name/*"
     ]
    }
   }
  },
  {
   "Sid":"Disallow other domains",
   "Effect":"Deny",
   "Principal":{
    "AWS":"*"
   },
   "Action":"s3:GetObject",
   "Resource":"arn:aws:s3:::YOUR-BUCKET-NAME/*",
   "Condition":{
    "StringNotLike":{
     "aws:Referer":["http://your-domain-name/*",
      "http://www.your-domain-name/*"
     ]
    }
   }
  }
 ]
}

Update! - Renamed the thread to better identify the issue and turned it in to a bug as there it presents a content security issue (see below).

First, the bucket policy above only works with Flash based players (that send a referrer). HTML5 based players don't send the referrer (in all browsers?), so the policy results denies access. Use with caution.

But- Here is where the "bug" part comes in.

If site admins wish to use the Video module in combination with Zencoder and Amazon S3, and also wish to use signed URLs, this is implies that they wish to secure the content, protecting it from public access. By default, all files placed in an S3 bucket will be private, accessible only via API calls (which the S3 & AWS SDK does on behalf of Drupal in the case of signed URLs).

Currently, the TranscoderAbstractionFactoryZencoder.inc file sends a hard coded "Public" as the permission of all Zencoder results published to S3. If one wishes to use signed URLs via S3 (wanting privacy), Zencoder will write the files back as public (readable without signed URLs) which negates the site admins intention when they chose signed URLs.

Without exposing the public / private option to the site admin, videos transcoded via Zencoder and placed in directories that the admin defined as secure will be publicly available via the direct URL, with no signature.

Pretty sure this is left over from before the Video module was able to support signed URLs, where everything had to be "public" in order for Drupal to access it. Now that Drupal + S3 can create the signed URL to pass to Drupal + Video upon request, we can keep things private and let Drupal + S3 do its job.

To fix as a hack, change line 126 of TranscoderAbstractionFactoryZencoder.inc from this:

$this->options['output']['public'] = 1;

To This:

$this->options['output']['public'] = 0;

A simple fix could be to expose the public private switch on the Zencoder profile settings page. A potential issue could be if users wish to pick and choose which directory to protect with signed URLs to protect, (60|mydir/*) and they do not keep a close eye on which directories they are putting videos created with the Zencoder profile with the private setting, or they will have files set to private, with Drupal + S3 not creating the signed URLs to allow access, this resulting in an error. A risk that can be addressed in a warning under the Signed URLs notice in the S3 module, and under the switch in the Zencoder profile.

Will do. Thanks!

The fix works great! Private permissions were respected. Thank you!