Google App-Engine supports version-specific routing of requests as documented here.
This is useful for example for testing a new version prior to deploying it.
However, this may also be problematic. Say the new version includes security enhancements - there should be a way to prevent access to previous versions without deleting them completely (in order to allow for quick roll-back for instance). Could not find a way to disable previous versions.
Is there a way to accomplish that ?
Thanks.
There is no way to disable default/soft/targeted routing on the appspot.com domain.
But you could analyze the request's url structure and specifically reject requests with such undesired urls.
Or, if you're using a custom domain, reject all appspot.com requests (see Disable default domain https://[project-id].appspot.com of Node JS on Google App Engine) and only leave the custom domain operational. Then the domain will be served following the service's traffic migration/splitting configuration which you'd manipulate in your deployments/rollback actions (you cannot route to a specific service version in the dispatch.yaml file)
Update: indeed, as comments mentioned, blindly rejecting all appspot.com requests isn't a good idea. Since URLs would need to be parsed to select the undesired ones it may be worthy to take the opportunity to redirect to canonical custom domain counterparts instead of just rejecting the requests.
Related
What is the correct way to map a custom domain to Google App Engine project?
I've added the custom domain, set up all the DNS records etc. and it is working! But how do I enforce HTTPS only? (Like the custom domain generated does)
From reading around many posts I have seen secure: always in a handler which I have tried, but doesn't seem to work (saw some comments that it doesn't work on flex environments?)
So how can I correctly map my domain to a flex php environment being HTTPS only?! Seems such a simple thing to want to be able to do!
While being somewhat related to a custom domain (for example the SSL certificate used by HTTPS being tied to the domain) the HTTPS-only behaviour is not really an attribute of the custom domain mapping operation, it's just a behaviour of the app itself (regardless of being mapped to a custom domain or not).
For standard environment GAE apps part of the HTTPS-only behaviour is an automatic http -> https redirection performed by the GAE infra on behalf of the app if secure: always is set in the app.yaml configuration file.
But that configuration has, indeed, been deprecated for the flexible environment GAE apps. The PHP-specific deprecation note can be found at app.yaml changes:
Secure handlers
The secure setting under handlers is now deprecated for the App
Engine flexible environment. If you need SSL redirection, you can
update your application code and use the X-Forwarded-Proto header to
redirect http traffic. You can also use the HTTP Strict Transport
Security response header.
You'll also note that there is no mentioning of secure (or handlers for that matter) in the app.yaml Configuration File doc.
So you need to take care of the http -> https redirection inside your app code (or the framework you use for it, if any and if it has such capability), possibly following the suggestions from the above quote. I can't really help with details on this as I'm not a PHP user.
I have an app engine service deployed in GAE (written in Node) to accept a series of click stream events from my website. The data is pushed as an CORS ajax call. I think, since the POST request can be seen in browser through the developer tools, somebody can use the app engine URL to post similar data from the browser console.( like in firefox, we can resend the URL. Chrome also has this features i guess)
A few options I see here is,
Use the firewall setting to allow only my domain to send data to the GAE.
This can still fail me since the requests can be made from the browser console repetitively)
Use a WAF ( Web Application Firewall) as a proxy to create some custom rule.
What should be my approach to secure my GAE service?
I don't think the #1 approach would actually work for you: if the post requests are visible in the browser's development tools it means they're actually made by the client, not by your website, so you can't actually use firewall rules to secure them.
Since requests are coming into the service after fundamentally originating on your own website/app (where I imagine the clicks in the mentioned sequences happen) I'd place the sanity check inside that website/app (where you already have a lot more context info available to make decisions) rather than in the service itself (where, at best, you'd have to go through loops to discover/restore the original context required to make intelligent decisions). Of course, this assumes that the website/app is not a static/dumb site and has some level of intelligence.
For example, for the case using browser development tools for replaying post requests you described - the website app could have some 'executed' flag attached to the respective request, set on the first invocation (when the external service is also triggered) and could thus simply reject any subsequent cloned/copy of the request.
With the above in place I'd then replace sending the service request from the client. Instead I'd use your website/app to create and make the service request instead, after passing through the above-mentioned sanity checks. This is almost trivial to secure with simple firewall rules - valid requests can only come in from your website/app, not from the clients. I suspect this is closer to what you had in mind when you listed the #1 approach.
Is there an elegant way to prevent requests from referrers outside the application? Looking at the app.yaml documentation, it doesn't seem like this is a in-box functionality but it seems like it'd be so preferred/common that it has to be hidden somewhere rather than necessarily having to reimplement it manually for every application.
It is built in.
In app.yaml you can specify login: admin for a handler and it would accept requests just from admin or from AppEngine (e.g. cron, taskqueues, and pribably urlfetch of the app itself - the last one not 100% sure).
See docs: https://cloud.google.com/appengine/docs/python/config/appref#handlers_element
Also you can check HTTP_HEADERS like referer, IP, user agent.
Also you can issue a token and pass/check it with every request.
There are probably a few issues being conflated here.
CORS - a browser enforced security measure to prevent pages maliciously or otherwise sending data to non-origin servers. Servers cannot enforce this, only permit it. Permitting this is an application level concern (i.e. Not built in to GAE)
XSRF - a server enforced security measure to stop authenticated users having their account abused by malicious client code. This is an application level concern (i.e. Not built in to GAE)
Authentication - identifying a user or client by some set of permissions. There is some support for this with GAE (cloud endpoints, provided identity service, requiring admin login), but it typically would also be an application level concern. In the case of authorizing a client (as opposed to a user) there is no built in support.
Authorization - different sets of access based on roles/permissions. Not built in.
Other solutions:
Using Host or Origin header - trivially outfoxed by someone implementing a curl request, or any application more sophisticated
API token - fine for server to server over https but trivially compromised when used on a published client (like a web page)
Your best bet is to leverage your framework and have user accounts.
If you don't want to do this, something like XSRF (token in a header and cookie) would be enough in the general case to ensure that a web client was responding to your 'app'. This only works if the client is a web browser though, same as origin/host.
No. There is no built-in logic in GAE for that. Any support would have to exist at the level of your application-specific request routing.
Problem I want to solve
I want to be able to send different users to different versions of my Google App Engine application, on a custom domain, with SSL enabled. This needs to be done in a controlled way, i.e., even landing page should be different, and it has to work on multiple units for the user.
Solution I can't get to work
I am trying to setup a custom domain with sub-domains, and want to be able to access different versions of the application. For example, I have myapp.mydomain.com, and I want to run one version (alpha) on alpha.myapp.mydomain.com, and one version (beta) on beta.myapp.mydomain.com (where alpha is default).
I use the Google Developers Console to set up custom domains, using myapp.mydomain.com, and *.myapp.mydomain.com as custom domains.
This works perfectly as long as I don't try to add on SSL as well, i.e., beta.myapp.mydomain.com serves the version named beta. When I set up SSL I start by adding my application to Google Apps, (per https://developers.google.com/appengine/docs/ssl) and then set up my domain to point to my app. First I add myapp.mydomain.com, then alpha.myapp.mydomain.com, and last beta.myapp.mydomain.com.
When that is done beta.myapp.mydomain.com start to serve the default version instead. Except that it sometimes also serves the beta version (this happens one in every 20 tries or so, I assume it's a glitch for now).
My questions:
a) Should I set up my domains in both Google Apps and Google Developer Console? Or should I remove the setup from Google Developer Console? I tried both, seems to give the same results.
b) It seems like it is possible to get it done by using modules as indicated in
Google App Engine custom domains, subdomains and SSL and in Appengine modules dispatch.xml routing with custom domain. Is this the only way, or am I doing something wrong in my setup?
Suggestions I have received so far
One suggestion is to use traffic splitting and set a unique cookie depending on what version I want the user to end up with. I did not know about this, and it will solve some other issues I have been looking at. It does not solve my current problem though, as I need to have this set before log in. The answer is useful though.
I'll answer with what I did to make this work for me.
Instead of sending users to different versions of the app, I created a new module called alpha, and directed users using alpha.myapp.mydomain.com to that module using dispatch.xml.
<dispatch>
<url>*alpha.myapp.mydomain.com/*</url>
<module>alpha</module>
</dispatch>
I set up custom domains in the App Engine Console (https://console.developers.google.com) under Compute->App Engine->Custom Domains, for *.myapp.mydomain.com and alpha.myapp.mydomain.com. I also added the URL alpha.myapp.mydomain.com to the accepted URLs for my App Engine app on Google Apps (https://admin.google.com). This allowed me to run over SSL as well.
I intend to run the app under another domain (domain alias to my primary domain), so I tried that as well. To make this work I ONLY added the domain alias in Google Apps as www.mydomainalias.com and alpha.mydomainalias.com, because if I added it to Google App Engine custom domains I got an error message ("We are unable to process your request at this time. Please try again later. (Error #1000)"). I have no idea why it that did not work out.
The easier approach is to do traffic splitting on a cookie level compared to setting up extra subdomains AND extra SSL certificates.
The domain name to access your alpha version does not have to change using this approach.
from the docs :
The response from your app does not already contain a Set-Cookie:
GOOGAPPUID=... header. This allows your app to control which version a
user gets.
For our e-commerce service running on AppEngine we would like to offer the option for customers to run the stores on their custom domains (eg: www.mystore.com instead of www.enstore.com/mystore).
From a user perspective, I'd like them to enter the domain name they want to use in their preference screen and tell them how to configure their dns.
I know how you normally add domains to an AppEngine instance (through Google Apps) but I'm not sure you can automate that. And even if that's possible they would be all (hundreds) listed on our google apps page.
Anyone know if this is possible/if there is a good way to do it?
I don't think there is a way to add domains "programatically" to an AppEngine instance. Apparently, domains can only be added by using the Google Apps method that you described. This is confirmed in this SO post: How do i get foo.somedomain.com get handled by myapp.appspot.com/foo on appengine
The only options that pop to mind are the following:
HTTP Redirection
Many DNS providers support HTTP Redirection. In this case, your clients would be able to set up mystore.com and www.mystore.com to redirect to www.enstore.com/mystore. There are some obvious disadvantages with this method that might not be acceptable. First of all, with 301 and 302 redirects, the users will still be forwarded to the registered AppEngine URL: www.enstore.com/mystore, and it will show in their browser. In addition, choosing between a 301 and 302 redirect can make SEO tricky, since you'd have to get into how search engines behave with these redirects. For example most search engines will not use the original URL as a source for keywords when you use a 301 redirect.
In addition to 301 and 302 redirects, some DNS providers (like DNS Made Easy) also provide what they call a "masked hidden-iframe redirect". The page will render inside a hidden iframe, so the URL does not change in the user's browsers. However this makes SEO even more tricky, and it will not allow users to bookmark internal pages, or to reference them easily.
As you can see, this option is less than ideal, but it is one option to consider in some situations. Also note that at the moment, HTTP Redirection using 301 redirects is the suggested workaround for the Naked Domain Issue 777 on the AppEngine issue tracker.
Reverse Proxy
Another option could be to set up a small server somewhere else, like a small Amazon EC2 Instance, and set up a simple reverse proxy. You would be able to set this up very easily, just by using Apache and mod_proxy (or various other alternatives). This would allow you to ask your clients to set up a normal A Record pointing to this instance, while the Apache HTTP server would be acting as a proxy to your AppEngine.
The fundamental configuration directive to set up a reverse proxy in mod_proxy is the ProxyPass. You would typically set it up with one line like these for each VirtualHost (for each client domain):
ProxyPass / http://www.enmystore.com/mystore/
The configuration of the remote proxy could be easily handled by your back-end software.
This is a neater solution which gives you plenty of control - but there are obviously some costs for these benefits. First of all, there is the expense to host the reverse proxy. You would also be adding another point of failure, so you have to add this to your high-availability plan. In addition, if you are serving some pages through SSL it can become quite complicated.
Another option is to have each customer sign up for google apps, and then add your appengine app to their app. That way they can manage the url. They will need to use a cname for this, so urls will be limited to something like 'store.customer.com' You will have to support the multitenancy off of the host-header, but that isn't hard to do given that you already have a way to support multitenancy already. You might want to do the setup for the first couple of clients yourself so you can document the easiest way to set it up.
The rietveld code review app does this as you can add it to your google apps domain. See http://code.google.com/p/rietveld/wiki/CodeReviewHelp#Using_Code_Reviews_with_Google_Apps for more detail.
The preferred option is probably to offer your solution through the Google Solutions Marketplace: http://www.google.com/enterprise/enterprise_marketplace/about.html
We did something similar to Daniel Vassallo second proposal.
We created a python app on the Heroku cloud
(there is no limit for connecting custom domains).
This app is using python requests 1.2.0 lib to get the correct page from your app engine application according to the request domain.
all you need to tell your clients is to put your Heroku app url as their CNAME
For naked domains you can always use wwwizer