I see that my AppEngine endpoint is listening to both HTTP and HTTPS, how do I disable HTTP endpoint?
http://project-id.appspot.com - I want to disable this.
https://project-id.appspot.com
You cannot exactly disable it, but you can force a redirect to the HTTPS one.
If the endpoint runs in the standard environment you just need to set the secure: always config for the respective handlers in the app.yaml config file:
always
Requests for a URL that match this handler that do not use HTTPS are
automatically redirected to the HTTPS URL with the same path. Query
parameters are preserved for the redirect.
If it's in the flexible environment things are a bit more complicated, follow this thread: Force SSL on App Engine Flexible Environment Custom Runtime
If you want to deny requests over http (non-ssl) then check value for X-Forwarded-Proto header and respond with error if its value it http.
This header is added by GAE. https://cloud.google.com/appengine/docs/standard/java-gen2/reference/request-response-headers
X-Forwarded-Proto [http | https] Shows http or https based on the
protocol the client used to connect to your application.
The Google Cloud Load Balancer terminates all https connections, and
then forwards traffic to App Engine instances over http. For example,
if a user requests access to your site via
https://PROJECT_ID.REGION_ID.r.appspot.com, the X- Forwarded-Proto
header value is https.
Related
I have a react app serving from "https://www.domain1.com" and the backend is served on a different domain "https://www.domain2.com". Api requests made from domain1.com to domain2.com are not simple HTTP requests since we are adding an Authorization header in all the requests. This leads to CORS OPTIONS request being made further increasing the latency of the app by a heavy margin.
1. Is there any way I can merge the 2 domains ?
2. Can I avoid CORS OPTIONS preflight requests for these non-simple HTTP requests if I keep the domains separate ?
Yes, you can avoid CORS Policy option in your backend side not in your frontend. Where the API is developed, CORS Policy must be allowed there. After allowing you can call API which is serving from other domain.
My current stack is pretty simple:
Backend: Django 2.1.1, python 3.6 I am running it on elastic beanstalk with an application load balancer. I have port 80 listening for HTTP and port 443 listenin for HTTPS with my ssl certificate selected. I did not select an SSL policy as I have no idea what these do.
Frontend: React, mainly using axios to do requests (axios.get, axios.put, etc). I have this hosted on two s3 buckets, mainsite.com, where all my static files are, and www.mainsite.com, which redirects HTTP to that site. I also have 2 cloudfront distributions which redirect HTTP to HTTPs, using the same certificate as the one I used for my load balancer. I then created 2 record sets and set the alias to the cloud distribution. When I try to do any request, I see in the console:
xhr.js:173 Mixed Content:
The page at 'https://fakesite.net/login'
was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint
'http://myenv-env.randomletters.us-east-1.elasticbeanstalk.com/rest-auth/login/'.
This request has been blocked; the content must be served over HTTPS.
What else do I need to configure? Do I need to change code, or is it all aws related.
I have a Google Cloud project running AppEngine with app id myapp. I've mapped this app id to the custom domain example.com. I've set the default version of myapp to www. It has the secure: always applied for all handlers in my app.yaml. This setting is used to redirect HTTP traffic to HTTPS. Finally, I added CNAME record for www.example.com. For each of these routes I've allowed Google to manage and auto-renew SSL Certificates. The settings panel looks like this:
This is great because all of the HTTP requests get routed to their corresponding HTTPS endpoint.
A few days ago, I was asked to make a new version of the app alpha and want to route that to https://alpha.example.com. Like the www version I set secure: always to enforce HTTPS redirects for alternate protocols. I also added a CNAME record for alpha.example.com and added the "Google-managed, auto-renewing" certificate to it. http://alpha.example.com correctly redirects to https://alpha.example.com but, https://alpha.example.com serves the default version of my application www instead of my new version alpha. New settings look like this in the App Engine Custom Domains dashboard:
What can I do to ensure http(s)?://(www)?.example.com serves version www, http(s)?://alpha.example.com serves version alpha, and ensure all content is served over https?
According to the custom domain docs:
Entering *.example.com maps all subdomains of example.com to your app.
This means that you'll have to manually handle your mappings in a dispatch.yaml file.
In your case, you'll want something like:
dispatch:
- url: "alpha.example.com/"
service: alpha
- url: "*.example.com/"
service: default
Be careful with the ordering of your rules, since the requests will be routed according to the first url pattern matched.
For a more in-depth explanation of how GAE standard routes requests, check the How Requests are Routed doc.
To keep the requests being redirected to the https version of the app, keep using the secure directive in your app.yaml.
I have an application where the client uses mutual SSL authentication through NGINX. So far, so good.
However, I want to move my project to Google App Engine and I need to use the same approach to valid the client, or at least, forward the client certificate to be validate in the application.
Is there some way to use mutual authentication on App Engine or other Google Cloud service?
Regards!
This might not be possible in GAE flexible environment because the SSL connections don't reach all the way to the actual application code. From Request limits:
SSL connections are terminated at the load balancer. Traffic from the load balancer is sent to the instance over an encrypted channel,
and then forwarded to the application server over HTTP. The
X-Forwarded-Proto header lets you understand if the origin request was
HTTP or HTTPs.
I didn't find such mention about the standard env GAE, so I'm unusure if the same applies there or not.
I have an App Engine server hosting an AngularJS application that makes CORS requests to some Cloud Endpoints APIs on another App Engine server. As per the $http service documentation I have enabled it to send credentials in cross-domain requests by settinga default header:
$httpProvider.defaults.withCredentials = true;
The front-end server has an associated custom domain with SSL support, and makes requests via HTTPS (so that both the ends are basically HTTPS).
My goal is sending an authentication cookie to the backend in order to manage resource access authorization, but for some reason this cookie never gets sent.
I do see the cookie in the request when the two servers are running locally (frontend: http://localhost:8081, backend: http://localhost:8080), but not when they're deployed.
What am I missing there?
angular http Documetation i follwed
Try adding this header to your HTTP calls {'Content-Type': 'application/x-www-form-urlencoded'}
If I understand correctly, you want to send an authorization cookie over CORS to a different (sub)domain?
To do this, you need to permit CORS requests on the initial page load, use 'withCredentials' as you have detailed as well as have a cookie for the targeted cross domain call. If it's cross domain, you'll have to write the cookie in js code, if it's a sibling subdomain make sure the cookie domain starts with a dot .domain.com, and the cookie will then be shared across all subdomains of the domain.
Localhost can play havoc with this kind of testing because the domain relationships are different (i.e. Not sibling subdomains) - you can try using a local proxy to set up a scenario which maps subdomains to a loop back address.