Closed chillu closed 5 years ago
@halkyon could you note down here why your PR was reverted?
@tractorcow How workable is the S3 module without this in place? I assume that the local-cache-on-upload mostly removes the need to stream S3 files through SS? The GraphQL requests still generate thumbnails, but they're basing those on locally cached files rather than getting anything from S3, right? And for pages with unpublished images, I assume the flow is similar (no direct S3 file content access)?
Also, should we create a separate issue for "S3 signed URLs" (http://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html). I'm not sure what's a more common use case - it sounds like given the relative ease of fronting S3 with CloudFront, the distribituion/CDN advantages, and the cost savings (on larger scales), it'll be a pretty common combination - more common than just serving straight from S3?
Is S3 signed URLs the baseline feature, or more of a special case?
Maybe I'm misunderstanding here, but everytime I was accessing an protected filed I got a signed URL directly to S3.
I didn't try with CloudFront, but it seems to be broadly working for me.
Right now all protected assets will have signed urls so feel this can be closed. If a user wanted to use CloudFront they could extend the ProtectedAdapter and ProtectedCachedAdapter to return specific cloudfront urls I believe. Also with the addition of #20 - caching and what not seems to greatly speed up the use of S3.
Overview
From https://github.com/silverstripe/silverstripe-assets/issues/52: "Initial performance testing shows that streaming s3 content directly though silverstripe is extremely inefficient, and in it's place we can use a combination of s3/cloudfront signed protected urls. These are time-limited urls that allow public access to private files."
Acceptance Criteria
Notes
@halkyon already implemented this through https://github.com/silverstripe/silverstripe-s3/pull/7, but it was reverted in https://github.com/silverstripe/silverstripe-s3/pull/8.