Now that CloudFront supports POST requests, is it possible to do browser-based uploads directly to CloudFront?
In theory, yes. However, there are very serious issues with support for anything but the most simple upload requests from a browser. For example, support for uploads to S3 via CloudFront using the multipart upload API is not possible due to the fact that CloudFront rips off the Authorization header from all of these requests. Amazon appears to be unwilling to fix this issue. This means you cannot support chunked requests from the browser if you target a CF endpoint or make any REST calls that require an Authorization header.
There is also an issue the prevents you from targeting differing CloudFront distribution endpoints (in order to more easily target different S3 from the same CF domain).
Related
I am unable to make S3 images hosting to work over HTTPS. I read that "Amazon S3 website endpoints do not support HTTPS." - docs
I'm fine with hosting my images over HTTP, however, when I put the following tag in HTML:
<img src="http://MY-BUCKET-NAME.s3-website.eu-central-1.amazonaws.com/images/51612809-741c-40c7-8c29-7b332be709d7.jpg">
Chrome requests
https://MY-BUCKET-NAME.s3-website.eu-central-1.amazonaws.com/images/c1612a09-741c-40c6-8c29-7b332be709d7.jpg
(notice http became https), which results in ERR_CONECTION_TIMED_OUT.
How to make it work?
As we discussed in the comments, Chrome doesn't like mixed content anymore, i.e. it won't let you embed http content on a website that's served via https.
Now there are multiple options to make this work:
Downgrade the main website to http (don't do this, it's a terrible idea)
Make the bucket or at least the objects that you embed publicly readable in S3 and use the native https endpoint that S3 offers. It will look something like this:
https://<bucketname>.s3.<region>.amazonaws.com/<object-key>.jpg
This has essentially the same costs associated with it as your current solution. You might need to do some annoying CORS stuff though.
Set up a CloudFront distribution in front of your bucket and configure it to serve content from S3. You can use an Origin Access Identity to secure the communication between CloudFront and S3 and even customize TLS-configurations in CloudFront. This will give you caching closer to your users but comes with extra costs.
We have some videos in an S3 bucket. they've been transformed using AWS Elastic Transcoder to .m3u8 / .ts
We want the users to be able to stream these videos on both a web app and a mobile app.
Now, we want to secure this streaming, so our videos won't get pirated.
So, our proposed solution is as follows:
Prevent public access to the S3 bucket
create a cloudfront distribution with the bucket as the origin
Only enable access to this CDN using pre-signed URLs/cookies
For web app: use a pre-signed cookie (set by an endpoint at our backend that requires authentication), so that it works well with HLS (since the app needs to fetch a new segment every few seconds)
But now we don't know what to do with our mobile app. We can't use pre-signed cookies since there's no browser, and we can't use pre-signed URLs, since we'll need a signed URL for each segment we need to fetch. Any suggestions and solutions are welcome.
For our similar use-case:
We used CloudFront url and not S3 signed url. Because S3 signed URL is valid at object level and not folder level.
For paid videos, security and access was managed by Lambda#Edge on viewer requests.
Although we used OAuth and database inside that lambda, but surprisingly, we didn't face any bottlenecks on Lambda#Edge. For future plans we considered using Redis for seamless access validation inside Lambda#Edge.
I'm using CloudFront CDN to simply cache my static contents in "Origin Pull" mode. The CloudFront origin is my website.
However, I've encountered a CORS problem. My browser doesn't let my web pages load my fonts files and SVGs from CloudFront.
After googling this matter a bit, I noticed that all blogs/tutorials explain how to enable CORS on an S3 bucket used as the origin for CloudFront, and letting CloudFront forward the Access-Control-Allow-XXX headers from S3 to the client.
I don't need an S3 bucket and would like to keep it that way for the sake of simplicity, if possible.
Is it possible to enable CORS on CloudFront? Even a quick and dirty solution, such as setting the access control header on all responses would be good enough.
Following up the comment above, CORS is a request made FROM a domain different of the TO domain. The key part to avoid this, is in the server which returns your requests return the header allowing cross origin requests.
Your fonts, which should be your website's assets, should be kept in the same server as your website, therefore CORS should not be an issue.
We have an aws s3 bucket that hosts our dynamic images, which will be fetched by web and mobile apps through https and with different sizes (url/width x height/image_name) i.e. http://test.s3.com/200x300/image.png).
For this we did two things:
1- Realtime resizing: I have a redirection rule in my s3 bucket to redirect 404 errors requesting non-existing image sizes to an API gateway that calls a Lambda function. The lambda function fetches the original image and resizes it and places it in a folder in the bucket matching the requested size.
We followed the steps in this articles:
https://aws.amazon.com/blogs/compute/resize-images-on-the-fly-with-amazon-s3-aws-lambda-and-amazon-api-gateway/
2- HTTPS: I created a cloudfront distribution with an SSL certificate and its origin is the s3 static website endpoint
Problem: Requesting an image from s3 using the cloudfront https domain always causes an 404 error which gets redriected by my redirection rule the API gateway, even if this specific image size already exists.
I tried to debug this issue with no luck. I examined the requests and from what I see things should work normally.
I'd appreciate a hint on what to do to better debug this issue (and what kind of logs I need to provide here).
Thanks
Sary
This solution relies on S3 generating HTTP redirects for missing objects, to redirect the browser to API Gateway to resize the object... and save it at the original URL.
The problem is two-fold:
S3 generated redirects don't include any Cache-Control headers, and
CloudFront's default behavior when Cache-Control is absent in a response is to cache the response internally for the value of a timer called Default TTL, which by default is set to 86400 seconds (24 hours).
The problem this causes is that CloudFront will remember the original redirect and send the browser to it, again and again, even though the object is now present.
Selecting Customize instead of Use Origin Cache Headers for "Object caching" and then setting Default TTL to 0 (all in the CloudFront Cache Behavior settings) will resolve the issue, because it configures CloudFront not to cache responses where the origin didn't include any relevant Cache-Control headers.
For more background:
What is Cloudfront Minimum TTL for? explains the Minimum/Default/Maximum TTL timers and how/when they apply.
Setting "Object Caching" on CloudFront explains the confusing UI labeling of these options, which is likely a holdover from a time before all three timers were configurable.
Is it possible to enable/disable caching a request through the AWS API Gateway in the response of the request?
According to this document: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html It appears that the most granular one can get in defining cache settings is enabling/disabling caching for a specific API function. What I am wanting to do is allow the response for the API request to dictate whether or not it is to be cached. (i.e. I want my end API program to be able to determine if a response for a given request should be cached).
Is this possible, and if so how can it be accomplished?
Configure your own CloudFront distribution, with the API Gateway endpoint as the origin server. CloudFront web distributions respect Cache-Control headers from the origin server. If you customize that response, this should accomplish your objective.
API Gateway, as you may already know, runs behind some of the CloudFront infrastructure already, so this might seem redundant, but this appears to be the only way to take control of the caching behavior.