feat: redirect HTTP to HTTPS#2153
Conversation
| - Field: 'host-header' | ||
| HostHeaderConfig: | ||
| Values: | ||
| - Fn::Join: | ||
| - '.' | ||
| - - !Ref WorkloadName | ||
| - Fn::ImportValue: | ||
| !Sub "${AppName}-${EnvName}-SubDomain" |
There was a problem hiding this comment.
What is this saying exactly? 🤔
if you go to http://workload.env.app.domain.com/path then redirect to https?
I thought what we wanted was something like if I go to http://<anything>/path redirect to https://workload.env.app.domain.com/path so that it also captures the default elb dns name but I might be misunderstanding!
Actions:
- Type: redirect
RedirectConfig:
Protocol: HTTPS
Port: 443
Host:
- Fn::Join:
- '.'
- - !Ref WorkloadName
- Fn::ImportValue:
!Sub "${AppName}-${EnvName}-SubDomain"
Path: "/#{path}"
Query: "#{query}"
StatusCode: HTTP_301
Conditions:
- Field: 'path-pattern'
PathPatternConfig:
Values:
!If
- HTTPRootPath
-
- "/*"
-
- !Sub "/${RulePath}"
- !Sub "/${RulePath}/*"
There was a problem hiding this comment.
I think we might just want to redirect http://frontend.env.app.domain.com/path to https://frontend.env.app.domain.com/path, and http://backend.env.app.domain.com/path to https://backend.env.app.domain.com/path.
|
Hi guys, thanks so much for releasing this feature! Is it possible to use it without tearing down my envs/app that are already live? Will it work if I just upgrade to copilot 1.5.0 and run By the way, is it possible for the test and prod envs to share the same certificate (& hosted zone) that would cover the whole domain (instead of having separate ones). I was trying to have CNAME / Alias records pointing across different subdomains, but it is triggering Certificate errors on the browser. Thank you and best regards, |
|
Hi @craquiest !
If you initialized your application with phases:
install:
commands:
- wget https://ecs-cli-v2-release.s3.amazonaws.com/copilot-linux-v1.5.0 # Use 1.5.0
- mv ./copilot-linux-v1.5.0 ./copilot-linux
- chmod +x ./copilot-linuxThen commit and push the buildspec so that the binary can generate the service templates with this new change :)
Not the at the moment apologies 🙇 I believe @iamhopaul123's |
|
Thank you @efekarakus , So I committed and pushed that change in buildspec.yml. But I keep get this error in the build phase. It is not the 1st time, so it is probably not be related to the release. I have already tried the instructions in the docker link. In essence I put my docker credentials in Secret Manager, and added the copilot-application & copilot-environment tags to the secret, for both prod and test. But it is failing more often than not. Isn't the caching system working in ECR , when the new code is deployed through the pipeline and codebuild? I do not understand why the 1st layers like getting python 3.9 and other pip install are being pulled everytime instead of tapping the cache... Am I missing something? Lamine |
|
@craquiest Oh noo looks like you got hit by the docker pull limit! A wrote this a while back which sounds similar to your secret manager work around: #1869 (comment) which has worked alright for me. If you don't mind can you take a look at it? I think while pushing it should realize that python3.9 is cached already in the repo and the push won't store the layer again but the problem seems to be while building the image itself. Since there is no cache for your codebuild builds, then each time it's downloading the layer again. |
|
@efekarakus, thanks, the parameter store workaround did the trick! awesome! and now the redirects from http to https work. I still do have the issue of the frontend not finding the backend after the pipeline finished. As I mentioned this back in Oct/November, I need to manually stop the frontend task in ECS and then when it re-provisions and starts, the connection to the backend works. I remember you saying it was maybe something in CloudMap, and that maybe a (back-then in version 0.5.0) previewed feature would fix it. I would really like to solve the problem this time around, as it throws off my continuity/availability for a few mins every time... Re: domain, what I am trying to do is simply point the {domain}.net, or at least the {appname}.{domain}.net to the production frontend frontend.prod.{appname}.{domain}.net - without having the whole 'frontend.prod' bit. I naively assumed that was what the |
Yay this is awesome to hear 😄
This is the same account that you emailed me earlier and in the region
Ok yes, then #1188 will definitely enable this usecase, stay tuned since we are actively working on the feature 😄 ! In the mean time for manual steps that can be taken check out this comment: #1188 (comment) Hope this help until we have the |
|
@efekarakus Thanks!
this worked like a charm. Can't wait for the http.alias field to come out.
Yes it is the same issue. But I moved the app to my business account. Same setup, same region. I will email you the details you asked. |
|
I am seeing an interesting behavior related to this:
|
|
Hello @gautam-nutalapati.
Is it not in the rules for the HTTP listener (HTTP: 80)? |
|
Rules for HTTP:80 listener is forwarding requests to target group but it is not redirecting them. |
|
That's the default rule we need to create the listener since the listeners are created in the env stack while those fancy listener rules like HTTPListenerRuleWithDomain are created in the svc stack. I think if you click |
|
You are correct! I see them now. I wasn't looking at the console correctly, I wrongly thought that all rules would be listed in that page itself. Sorry for raising an invalid issue. |
|
It's totally fine! Don't worry about it. I'll let the Console team for ELB know of this feedback |
<!-- Provide summary of changes --> Part of aws#1188. Redirect HTTP to HTTPS if possible. <!-- Issue number, if available. E.g. "Fixes aws#31", "Addresses aws#42, 77" --> By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
6 participants
Part of #1188. Redirect HTTP to HTTPS if possible.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.