I am trying to enable HTTPS on my Go App deployed to GAE flex environment. I have my custom domain successfully mapped, and am using Google-managed SSL certificates. I have app.yaml configured to redirect HTTP to HTTPS as follows:
handlers:
- url: /.*
script: _go_app
secure: always
Now there are two problems that I haven't been able to resolve so far.
First, the above configuration is supposed to redirect HTTP traffic to HTTPS, but apparently it is not happening.
Second, when I add https:// in the url box, I see three different behavior on Firefox, Chrome, and Edge. Edge identifies the website as secure, Firefox marks the website as secure connection, but says that it "has blocked parts of this page that are not secure", and surprisingly Chrome marks the website as Not secure (though it says certificate is valid!).
With these symptoms I was wondering if I should take additional steps to make redirecting and SSL work for my website? Specifically, I would like to know with App Engine, and managed SSL enabled:
Should I continue serving pages on HTTP using http.ListenAndServe(..), or need to switch to http.ListenAndServeTLS(..)?
In my Go app should I redirect HTTP to HTTPS? or the above setting is expected to work just fine?
Thanks in advance for your help and advice.
PS:
Trying out with different suggestions, I added Strict-Transport-Security: max-age=31536000; includeSubDomains to handlers' response. Does not seem if this helped with redirection either.
EDIT/PARTIAL ANSWER:
According to this documentation, under Authentication changes, the secure and login handlers are deprecated. The documentation suggests using Strict-Transport-Security or X-Forwarded-Proto instead.
I am using Strict-Transport-Security on the server side to enrich my response header:
func (h *STLHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) {
w.Header().Add("Strict-Transport-Security", "max-age=63072000; includeSubDomains")
h.nextHandler.ServeHTTP(w, req)
}
I was wondering if I am using this header in the right place?
For the second set of my problems I realized I have mixed content on my page. My mixed content was a http link to a set of fonts. When I fixed the mixed content, i.e. changed http to https, both Chrome and Firefox security warnings disappeared. You may also find this page Avoiding the Not Secure Warning in Chrome useful on this matter.
You need to check your app using:
http://[YOUR_PROJECT_ID].appspot.com
Or if you nedd HTTPS:
https://[YOUR_PROJECT_ID].appspot.com
If you want your own certificate you will need to upload it and then be available to use: https://your-domain.tld
From the docs:
For APIs that will be hosted on App Engine flexible environment, you must use the appspot.com domain, and the service name must be in the following format:
YOUR_PROJECT_ID.appspot.com
When you deploy your API to App Engine, a DNS entry with a name in the format YOUR_PROJECT_ID.appspot.com is created automatically.
For APIs that will be hosted on Compute Engine, Kubernetes Engine, or Kubernetes, you must use the cloud.goog domain, and the service name must be in the following format:
YOUR_API_NAME.endpoints.YOUR_PROJECT_ID.cloud.goog
Or you could just put a CDN in front like Cloudflare which will do all the SSL termination for you and if required redirect all HTTP to HTTPS
Related
I am working on setting iframe and stuck with local testing. I have my app running on localhost:3000
I have setup Iframe in my app with src url set to localhost:1234 for local testing. I was hoping accessing via local host would resolve the cross origin error but looks like since port numbers are different, this doesn't seem to work
SecurityError: Blocked a frame with origin "http://localhost:3000" from accessing a cross-origin frame.
I have looked into various stack overflow posts and tried disabling chrome web security, even then this doesn't seem to let me do some local testing.
Any suggestions on how to prevent the cross origin error in this case?
Thanks!
Your app (the backend) should send a CORS header (from localhost:3000 if I understand correctly). A different port (just like a different hostname) counts as a different origin, so the same origin policy applies to requests, and you have to explicitly enable cross-origin requests.
The way to do so is your "backend" must send the response header
Access-Control-Allow-Origin: localhost:1234
if that's where your frontend app is running. For development, you can also send
Access-Control-Allow-Origin: *
Don't do * in later stages of your pipeline and especially not in production as you might open your app to further vulnerabilities (CSRF).
If your frontend app uses cookies to authenticate cross-origin, the backend must also send Access-Control-Allow-Credentials: true, and your frontend javascript must add withCredentials: true to the request. However, it doesn't sound like this is the case for you.
I think this is better than disabling cross-origin restrictions as this would work for any developer without any setup, and without compromising browser security. It gives you full control over which client can access your API, and also allows you to understand cross origin requests better.
I was able to do local testing via Safari following the steps here:
Safari -> Preferences -> Advanced
then at the bottom tick Show Develop Menu in menu bar
then in the Develop Menu tick Disable Cross-Origin Restrictions
Cross-Origin Resource Sharing is disabled on some modern browsers by default. Allow CORS: Access-Control-Allow-Origin plugin for Chrome adds necessary HTTP headers to perform development on localhost without CORS error.
I have mapped my custom domain to GAE custom domain mappings. My domain resides at godaddy.com.
The mapping works and it always points to non-secure site, where as a secure site does exist.
I want on typing non secure site it should auto direct to secure site. I tried to use forward mechanism on loads, but somehow it gets in a loop from secure to non-secure.
You can try the following 3 approaches :
To send HTTPS requests with your custom domain, you can use the
managed SSL certificates, like mentioned here which says
“By default, HTTPS connections on your custom domain will be enabled
automatically using managed SSL certificates”.
To force HTTPS for your app, you can specify the secure: always
element for each handler in your app.yaml. Using secure: always
redirects all HTTP traffic to an HTTPS URL.
For example:
handlers:
- url: /.*
script: auto
secure: always
redirect_http_response_code: 301
To instruct the browser to prefer https over http for a given page or
entire domain, set the Strict-Transport-Security header in your
responses. Add the header to your app's static file and directory
handlers.
For example:
Strict-Transport-Security: max-age=31536000; includeSubDomains
I've created a GAE project and I deployed two services:
default (https://myservice.appspot.com) for the front-end app
backend (https://backend-dot-myservice.appspot.com) for the backend (Node.js)
I've also added a custom domain so that the default service is reachable also at https://myservice.com.
The problem I have is that each AJAX requests performed by the browser is preceded by an OPTIONS request (to handle the CORS).
What's the best solution to avoid this OPTIONS request? It should be fixed if both front-end/backen-end are on the same host, but how can I do it on Google App Engine?
Thank you!
I solved adding a dispatch.yaml file on the default service
dispatch:
- url: "*/api/*"
service: backend
where backend is my backend service.
And I changed my backend in order to listen on addresses like /api/something.
So now the browser has origin https://myservice.com and the url of ajax requests to the beckend are like https://myservice.com/api/something.
Since now client and server have the same origin, the CORS settings is not needed anymore, and the OPTIONS request is not performed by the browser.
I don't know if it's the best solution, but for me it worked.
As it was mentioned in this Stackoverflow post:
OPTIONS requests are pre-flight requests in Cross-origin resource sharing (CORS).
This pre-flight request is made by some browsers as a safety measure to ensure that the request being done is trusted by the server. Meaning the server understands that the method, origin and headers being sent on the request are safe to act upon.
Your server should not ignore but handle these requests whenever you're attempting to do cross origin requests.
CORS Support for Google App Engine in your app.yaml:
One important use of this feature is to support cross-origin resource sharing (CORS), such as accessing files hosted by another App Engine app.
For example, you could have a game app mygame.appspot.com that accesses assets hosted by myassets.appspot.com. However, if mygame attempts to make a JavaScript XMLHttpRequest to myassets, it will not succeed unless the handler for myassets returns an Access-Control-Allow-Origin: response header containing the value http://mygame.appspot.com.
handlers:
- url: /images
static_dir: static/images
http_headers:
Access-Control-Allow-Origin: http://mygame.appspot.com
Note: if you wanted to allow everyone to access your assets, you could use the wildcard '*', instead of http://mygame.appspot.com.
On configured AKS there is docker container with application that is using AAD authentication.
Based on this article there is also configured ingress. API is working well.
When I add to Azure Active Directory application registration reply URL with https prefix I receive error "The reply url specified in the request does not match the reply urls configured for the application". And I see that in browser address line redirect_uri is starting with http.
When I add reply URL that is starting with http, then I receive "Exception: Correlation failed".
What I have tried: Add to ingress.yaml setting ingress.kubernetes.io/force-ssl-redirect: "true"
May be there is some way to force ingress run https instead of http, or there might be some AAD redirect configuration? Any ideas?
UPDATE 2: Probably http redirect is because of ADAL.
PS: Was able to find similar topic without an answer
UPDATE3:
I have decided not to use nginx as ingress. Instead I am using now Load balancer. Soon it would be possible to use Azure Application Gateway Ingress Controller
Have you tried this?
By default the controller redirects HTTP clients to the HTTPS port 443 using a 308 Permanent Redirect response if TLS is enabled for that Ingress.
This can be disabled globally using ssl-redirect: "false" in the NGINX config map, or per-Ingress with the nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation in the particular resource.
More information on this on the Ingress documentation link.
You have to make a decision whether to use HTTPS or not. If this is just the start of a development cycle, start without it and get auth to work - but implement HTTPS as soon as possible.
AAD supports both http and https, but of course, the reply urls must be added to the application registration respectively.
As #mihail-stancescu says, ssl-redirect must be set to false, if you choose not to use HTTPS. In addition to this, you also have to ensure that your app does not make the redirect from HTTP to HTTPS.
Using curl with -L -k and -v options will give you a lot of information on what is actually happening with your requests.
When the http/https thing is solved, you have to remove any rewrite annotations you have in your ingress. (e.g. ingress.kubernetes.io/rewrite-target: / should be removed).
Now, if your ingress path to the service in question is e.g. /myservice, then the reply-url should also have that part of the path added ([host]/myservice/signin-oidc) - both in the AAD application registration and in the configuration of your app. (The path in the config should not contain the host)
If you are using https, then you must also have a proper certificate. You can use the free LetsEncrypt (https://letsencrypt.org/) in conjunction with KubeLego (https://github.com/jetstack/kube-lego), where you can find some nice examples on how to implement it.
I'm trying to work with Kubernetes API server from Angular JS front-end app. The API server uses https endpoint. The front-end app is deployed to the other server.
Despite the --cors-allowed-origins=.* (or --cors-allowed-origins=["http://*"]) param for kube-apiserver I can't access API because when I try to make GET XHR request, pre-flight OPTIONS request failed with 401 response without CORS headers.
However, when I switch from https to http, everything works fine.
Looks like I'm facing this issue, which is already fixed and merged in the version of Kubernetes I'm using.
Versions are Kubernetes 1.2.4, Angular JS 1.5.4 and Chrome 51.
Could you tell me why it happens and how to fix this? I need a working solution for https.
The issue you linked to was fixed, but a regression in CORS handling was introduced by kubernetes/kubernetes#18113 and has yet to be fixed (see kubernetes/kubernetes#24086). It is currently marked as a known issue for the imminent 1.3 release, which means that it is an outstanding bug.
You can edit kubernetes API server yaml file, to get CORS working.
Location: /etc/kubernetes/manifests/kube-apiserver.yaml
Add - --cors-allowed-origins=http://www.example.com,https://*.example.com this line under kube-apiserver
spec:
containers:
- command:
- kube-apiserver
- --cors-allowed-origins=http://www.example.com,https://*.example.com
Coma separated domains or regular expressions you can add.
No need to restart kube-apiserver, once file saved kube-apiserver will automatically restart.
it will take 5 to 10min time to get API server up.