I have an application which is hosted in S3 bucket and that is exposed to the public via CloudFront. OAI is use to access the content from the S3.
In this application, we have complex URL patterns and we are getting 400 error for some of the URLs due to incorrect URLs patterns(invalid encodings, etc). Eventhough, CF is allow to set custom error pages, we cannot place a custom error page for these requests because these requests blocked from the CF level and not forwarding these requests to the OAI. As per the AWS documentation, error pages can be set for the HTTP error codes which are coming from the OAI level. Therefore, I am trying to find the solution for this issue with existing architecture. Please let me know if you have some solution for this.
I need to display a custom page for the 400 errors coming from the cloudfront
Related
Iam getting 504 error on my app when trying to upload a document(nearly 10mb) to API POST endpoint.
I've already tried creating custom rules to allow the URI path of the API and also created condition within a size limit for body as well as http method.
The WAF log is showing ALLOW for the request but document is not getting uploaded and getting error.
when I disassociate the API from WAF, everything is working fine.
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.
I have setup S3 with CloudFront to serve static site behind Basic HTTP authentication, similar to this setup here: Basic User Authentication for Static Site using AWS & S3 Bucket
Everything seems to work fine, but for some reason when I do a refresh of the site, CloudFront responds with 403 AccessDenied. This is also happening only when navigating somewhere to the site, like example.com/somepath and refreshing the site. If I stay at the root level: example.com and hit that refresh button everything seems to work fine.
I have configured routing on react app, so just to be clear that when navigating site via application links all seems to be normal. Only refreshing the page causes above issue. I have static website hosting disabled on S3 as I don't want anyone accessing my S3 files via S3 links directly.
I have added a custom Error Page to the CloudFront distribution. For all 403 errors it should fetch root from origin / and return 200 HTTP status code.
Any ideas where to look for the issue?
The issue was with the incorrectly setup CloudFront distribution error page. Having error page configured for the 403 error to navigate to the S3 bucket root with the HTTP status code 200 solves the issue. It just took some time to take it into effect thus causing confusion.
This is more of a general question to see if anyone has encountered similar behaviors with AWS Cloudfront. I've had a distribution running a static website with Geo-restrictions applied as follows:
However, when looking at the logs, I see the following:
So my question is - Is CloudFront monitoring ALL requests, even restricted ones? I would think Geo-restriction would implement an ACL and would block all requests at the network level before getting to the distribution to request data.
CloudFront does not block geo-restricted requests at the network level. It serves a 403 response, which you can customize.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html
CloudFront returns an HTTP status code of 403 (Forbidden) to the user.
You can optionally configure CloudFront to return a custom error message to the user, and you can specify how long you want CloudFront to cache the error response for the requested file; the default value is five minutes.
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.