Having trouble setting a cookie (subdomain to parent) in a CloudFront configuration:
S3 bucket serving a static site with a CloudFront distribution. CNAME: example.com
API Gateway API with a custom domain: api.example.com
S3 bucket with a CloudFront distribution with CNAME: files.example.com
The web application on example.com contacts a lambda proxy GET method on api.example.com. This function, among other things, returns headers with values generated by AWS.CloudFront.Signer.getSignedCookies()
{
'Set-Cookie': `CloudFront-Expires=...; Domain=.example.com`,
'SEt-Cookie': `CloudFront-Signature=...; Domain=.example.com`,
'SET-Cookie': `CloudFront-Key-Pair-Id=...; Domain=.example.com`
}
These are being sent to the client with the response, but for some reason are not sent in GET requests to the S3 bucket on files.example.com.
I am not certain if the issue is with the cookies being set or being sent: By looking at the application tab in chrome dev tools it seems that the cookies aren't there. However, in the network tab the cookies are indeed being sent alongside requests to api.example.com (but not with requests to files.example.com).
As far as I can tell the configuration should work in terms of Domain cookie policy (the subdomain is attempting to set a cookie with a parent domain, under which is a different subdomain of the parent, that should receive the cookies). Any other immediate suspects for this sort of behaviour?
You want to use the cookie domain .example.com instead of example.com. The leading . allows subdomains to access the cookie as well.
You also need to ensure that the cookies are being forwarded to the origin in your CloudFront behavior.
Related
I am looking into using aws cloudfront with signed cookies to serve static protected content on my webpage. AWS documentation here says we should set 3 cookies which should be passed those to our cloudfront urls (images/css/html/js/etc). Its not clear how do to this as cloudfront will be a separate domain than the one which served the page.
mywebsite.com will server a page which has links to static CDN content on mycloudfrontsubdomain.cloudfront.net and should pass the signed cookies to gain access. How do I set cookies on cloudfront.net from my own domain or is there some way AWS can do this for you. Im not great with front end web development (Im mostly backend) but my understanding is we cant set cookies for a different domain that did not serve up the current page. I would assume AWS has some endpoint we could call to have cloudfront set cookies?
Cloudfront supports alternate domain names.
For example, you can set your Cloudfront distribution to have an alternate domain name of mycloudfrontsubdomain.mywebsite.com. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LinkFormat.html#LinkFormat_OwnDomain
Now you can set a cookie from mywebsite.com with a domain of mywebsite.com. Cookie with that domain will also include all subdomains (so also including cloudfront). https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#attributes
I'm using cloudfront to redirect a web app to a S3 bucket for some media content. As we trying to add HTTPS to our test environment, we wanted to add the https://app.foo.com origin to our cloudfront distribution. We've tried two different ways:
On the Create Origin tab, creating the second origin with the https
By editing the first working origin (in http) and adding a second origin header beneath the first one (in the origin settings tab).
None of these solutions seems to works, the app with http origin can access the bucket content. But the redirection with https does not work. I must precise that our authorizations on the bucket are ok, we can access the bucket content with the CloundFront link, and the CORS rules accept both http and https for the app. It looks like the https origin is not processed by ClondFront.
Thanks in advance
You need to understand what CloudFront is. It isn't "redirecting" users to an S3 bucket like you state in your question. It is loading, and caching the contents of the S3 bucket, and serving it to the user on request. An origin isn't a location for CloudFront to redirect users to. An Origin is a location for CloudFront to load resources from. In the context of http vs. https connections and CloudFront, you have the following decisions to make:
Will CloudFront communicate with the origin via http or https. This decision will not affect your users ability to load http or https resources in any way.
Will CloudFront serve both http and https content to your users, or will it redirect all http requests to https. This decision is not impacted by the origin configuration in any way.
The user's web browser is making an HTTP connection to a CloudFront server, and receiving the response from CloudFront. The user's web browser is never making a connection directly to S3.
You can't have two origins that only differ by http/https protocol. Both of those origins would be at the same path, and contain the same content. CloudFront only wants one of those origins, which it will connect to as needed to populate its cache.
I have a AWS Cloudfront hosted webpage which takes static pages from S3 and makes calls to custom origin (ALB) for dynamic data. There is OIDC authentication enabled on ALB, so calls to custom origin (my API) passes via rules set at ALB.
In a particular case when my request to custom origin is unauthenticated I am redirected to IdP for login and after successful login I get the cookie in the response header, as this request was sent to IdP from ALB - the issued cookie has domain as ALB DNS. In order for my webpage to use this cookie I have to redirect the call to Cloudfront URL. Now the cookie was issued to ALB which has a different DNS and my Cloudfront URL has a different DNS therefore I am unable to use the cookie.
I tried to catch the cookie value but because it is issued for a different domain i am unable to catch hold, also as a part of design I feel that is wrong. Has some one faced similar type of issue.
AWS ALB OIDC sets session cookie for the same request host domain for which you configure the authentication action in the listener rules.
Also, they set a http only secure cookie, meaning you cannot access it via client side Javascript at all.
Considering this along with your setup, it seems you actually need a (tiny) backend for your web page, so that you can access the response cookie when you make the API call to the mentioned custom origin internally from this backend.
I have my website like this "https://hr.mywebsite.com", I am able to go to my website when i type the whole url(https://hr.mywebsite.com).
But I want to go to my website without typing "https://".
That is if i type "hr.mywebsite.com" it should open my website. My website is hosted on AWS CloudFront.
You need to set an HTTP to HTTPS redirect on your CloudFront distribution. CloudFront has a setting for this.
To configure CloudFront to require HTTPS between viewers and CloudFront
Sign in to the AWS Management Console and open the CloudFront console at https://console.aws.amazon.com/cloudfront/.
In the top pane of the CloudFront console, choose the ID for the distribution that you want to update.
On the Behaviors tab, choose the cache behavior that you want to update, and then choose Edit.
Specify one of the following values for Viewer Protocol Policy:
Redirect HTTP to HTTPS
Viewers can use both protocols. HTTP GET and HEAD requests are automatically redirected to HTTPS requests. CloudFront returns HTTP status code 301 (Moved Permanently) along with the new HTTPS URL. The viewer then resubmits the request to CloudFront using the HTTPS URL.
Important
CloudFront doesn't redirect DELETE, OPTIONS, PATCH, POST, or PUT requests from HTTP to HTTPS. If you configure a cache behavior to redirect to HTTPS, CloudFront responds to HTTP DELETE, OPTIONS, PATCH, POST, or PUT requests for that cache behavior with HTTP status code 403 (Forbidden).
When a viewer makes an HTTP request that is redirected to an HTTPS request, CloudFront charges for both requests. For the HTTP request, the charge is only for the request and for the headers that CloudFront returns to the viewer. For the HTTPS request, the charge is for the request, and for the headers and the object that are returned by your origin.
From http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html
Here is my AWS Route 53 Setup:
The domain https://www.migranthire.com doesn't work. How can i redirect from this domain to https://migranthire.com
Your www site is pointing directly to an S3 bucket web site hosting endpoint, which is taking care of the redirect to the domain name without the www prefix.
The S3 website endpoints do not support HTTPS, so this works for http only.
Your solution is to create a second CloudFront distribution -- you need an additional one, because the second one has a different origin. Configure this distribution with your SSL certificate, configured to expect the www hostname as an alternative name, and set its origin to the www bucket -- however, when you are setting up this second CloudFront distribution, do not select the name of your bucket from the list. Instead, enter the website endpoint hostname -- www.migranthire.com.s3-website-eu-west-1.amazonaws.com. Set the origin protocol to HTTP only (CloudFront has to send the request to the bucket as HTTP even if the viewer protocol is HTTPS. You still get a green lock.)
Then, configure Route 53 to send www requests to the new CloudFront distribution, instead of directly to the bucket. CloudFront will speak SSL, sent the request to S3, which will return the redirect, as it is doing now.