I'm using grrr-amsterdam's redirect microservice on a CloudFront distribution that redirects to an Http Api.
I want to redirect www subdomains to my apex domain.
I can deploy successfully, but I get a 403 error when visiting www.example.com. I think the issue is with the Lambda's permissions, but when I add, in my cloudfront_stack.py
www_redirect.add_to_role_policy(
iam.PolicyStatement(
actions=["lambda:GetFunction"],
resources=[
f"arn:aws:lambda:us-east-1:{cfg.AWS_ACCOUNT}:function:{www_redirect.function_name}:{www_redirect.current_version}",
],
)
)
I get a deploy error based on circular dependencies. (I have attempted extending the permissions as described here.)
There is another problem. If I visit https://www.example.com, I get an SSL_ERROR_NO_CYPHER_OVERLAP from Firefox, or a Can't establish connection from Safari. To me it looks like the edge function is being called before the CloudFront's HTTP to HTTPS redirect.
Could someone offer solutions that are within the aws_cdk flow?
Related
I have a static site through Cloudfront with an S3 origin & custom domain via Route 53. All works well, except that Google has also indexed the Cloudfront distribution url (d123etc.cloudfront.net) as well as my custom domain, leading to duplicate content issues.
I've tried canonical urls, but the distribution remains indexed. It has been suggested to serve up a different robots.txt depending on what domain is being used, which sounds fine, but there is no .htaccess or web server, leaving it to a Lambda Edge function to try and send the different robots.txt.
The problem is that I can't find how in the function to determine if a request is coming from my custom domain or from the direct distribution url. I've tried white-listing the Origin, but it is not sent through when using an S3 origin. I've also tried white-listing the Referer header, but no referrer is sent through when accessing the robots.txt file as it's a direct request.
For the time-being, I'm adding a meta noindex client-side using js on page load (which I realise is too late), and also redirecting client-side to my actual domain in case someone follows the google indexed cloudfront.net domain.
Does anyone know how to detect in Lambda Edge which domain is being used to make the request? Or some other way of blocking Google from indexing the Cloudfront url, just leaving it to index the custom domain.
So I think the way to do this would be to set up a redirect on your hosted webserver. If you check the 'host' in the request header and check for cloudfront.com, send a 301 response code along with your custom domain name.
S3 has a UI way to do this:
https://medium.com/tensult/how-to-do-site-redirection-using-aws-522a4002c645
It seems you'll need a second bucket behind the same cloudfront url but without the custom domain. Then you can set it to redirect all requests to your custom domain.
The browser or bots would then stop trying cloudfront.com because it doesn't return anything, they would automatically (without the user really noticing) to my domain.xyz and all the links would link to your own domain.
Netlify noob here.
I'm currently migrating an old Ruby on Rails app to use Netlify for a static site. There are some legacy static pages that we want to keep on our old code base, and these legacy static pages make POST requests to our server.
It seems like redirects for POST requests aren't possible (see the W3 documentation for 301/302 redirects- If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.), but I was wondering if this is different when you proxy/rewrite the URL.
Currently, we rewrite a user's request to www.domain.com/legacy_slug via Netlify's splat redirect (similar to what the author of this blog post did). Is it possible for this redirect to work as well when the user sends a POST request to www.domain.com, causing it to go to Netlify? Or would I have to change the client's code to POST to <different_subdomain>.domain.com/legacy_slug and migrate the POST endpoint to the different subdomain?
Proxies (https://www.netlify.com/docs/redirects/#proxying) accept POSTs, redirects (https://www.netlify.com/docs/redirects/#basic-redirects) or rewrites (HTTP 200 that transform from one path to another, both on netlify-hosted sites), no.
Kind of a subtle distinction. So - I'd send the POST to some other path (not some other domain - just /place-we-post-to on your Netlify site, and use a proxy redirect to get to your remote service (/place-we-post-to https://legacybackend.com 200 in _redirects)
So I had github pages set up with a custom domain without problem on namecheap a day ago. Then I tried switching to Https via github's newly added support for https on pages. After too much frustration I switched over to CloudFlare for Https but I'm now getting an error ERR_TOO_MANY_REDIRECTS
Here's my DNS settings on CloudFlare.
Check your SSL setting in the Crypto tab. You should have it set to "Full". If it is set to "Flexible", then Cloudflare will use HTTP to connect to the origin, even when the client browser connects to Cloudflare over HTTPS. GitHub is probably responding with a redirect to HTTPS in this case -- not realizing that the original client is already using HTTPS, and so this redirect creates a loop.
More info here:
https://support.cloudflare.com/hc/en-us/articles/115000219871
The two typical causes of redirect loop errors are:
Cloudflare SSL options that are incompatible with your origin web
server’s configuration, and
Page Rule misconfiguration.
you can update in Custom domain github pages
https://github.com/yourusername/yourusername.github.io/settings/pages
Custom domains allow you to serve your site from a domain other than xxx.com with www, i was clear this issue with this way.
I have a site hosted on GitLab pages and using Cloudflare to manage the domain DNS, when I try to access the site using mysite.com it returns the website like it should, but when I enter www.mysite.com it returns an error 404 page from GitLab something like this GitLab error 404 page
I have tried to create page rules on Cloudflare but it's doesn't seem to have resolved the problem (yet), It's been over 10 hours, I have no idea how long this should take or if I am doing the right thing in the first place.
I am using the Python requests module (requests (2.7.0)) and tracking URL requests.
Most of these URL's are supposed to trigger a 301 redirect however for some the domain changes as well. These URL's where the 301 is causing a domain name change i.e. x.y.com ends up as a.b.com I get a certificate verify failed. However I have checked and the cert on that site is valid and it is not a self signed cert.
For the others where the domain remains the same I do not get any errors so it does not seem to be linked to SSL directly else the others would fail as well.
Also what is interesting is that if I run the same script using curl instead of requests I do not get any errors.
I know I can suppress the request errors by setting verify=False but I am wondering why the failure occurs only when there is a domain name change.
Regards,
AB
This seems to work now. I believe the issue was linked to an old version of openssl. Once I upgraded even the 301 for a different domain goes through with no errors and that was with verify set to True.