Hi fellow appengine developers,
we have a major impact issue on an european bank application, which is their first Google Apps and Google Cloud experience. We'd need this to be addressed to keep the trust that Google can provide the service. Is there any option to get such a major issues fixed in a reasonable time? Preferably other than paying for a premier account, which is not needed for this pilot product at this time.
The issue was already reported on appengine public issue tracker for over a month: http://code.google.com/p/googleappengine/issues/detail?id=7979
App Engine returns 403 on http://customdomain.example.com, instead of redirecting it to https, when secure:always is set in app.yaml. Authentication for the application is set to Google Apps domain, which may (or may not) play role in triggering the issue.
http://appid.appspot.com redirects correctly to https://appid.appspot.com
http://customdomain.example.com -> returns 403
https://customdomain.example.com -> works
Thanks for a beautifully designed service otherwise
Jan
Update:
The issue has proven link to Google Page Speed service. Whan disabled in application console, the redirect works ok. When re-enabled, it fails again.
The issue is observed on production application with PageSpeed, VIP SSL, Google Apps domain authorization, Google Apps data set to store in EU Data Centers only.
The issue is not observed on testing application with PageSpeed, SNI SSL, Google Apps domain authorization, without EU data location restriction.
As a temporary workaround, we commented out secure:always for the site entry url's in app.yaml, and decorated their handler methods with https://gist.github.com/3974365.
There's also google group discussion, if you have similar issue, or look for solution.
https://groups.google.com/d/topic/google-appengine/w3aKx9KxYoU/discussion
Maybe this will help, until the issue is fixed. In webapp2 you can restrict URI schemes. This means: when you allow http and https, you can define two routes for http and https and redirect to https if http was chosen.
Webapp2: http://webapp-improved.appspot.com/guide/routing.html#restricting-uri-schemes
Related
I've looked at previous questions enter link description here, but they use the GSuite Administrator to make changes, while my app uses GCloud. The domain registrar is separate since Google domains don't work in my country.
I mainly followed this guide to setting up my Zones and updating the name servers. I've configured the
https://cloud.google.com/dns/docs/update-name-servers
The question I linked to earlier recommended setting up a www. subdomain, but it used Authenticator. I'm not sure how to do this in a zone. I set up all the records properly in my domain registrar.
Here are the settings:
When I load the site itself (There's no actual HTTP response code):
And when I try the www. subdomain
I'm sure there's a step I'm missing, but this is my first site with GCloud. So I'm not very familiar with the process.
I think where is your missing step.
When you ask Google to use your domain, Google will expose HTTPS endpoint. HTTPS requires a certificate, and Google will generate it for you. However, before doing this, Google has to be sure that the domain belong to you.
You have to prove to google that you own your domain. For this, go to this page, log in and add a property (your website URL). Follow the instruction and be sure that your property has been validated.
Then, wait some minutes (hours?) the time that the certificates are generated and deployed.
I have a GAE app and a custom domain registered on enom.com. The app is a static website that's configured by app.yaml.
I'm trying to use LetsEncrypt certs for ssl, so I want to have valid certs for both www.example.com and example.com. I can get the cert for www.example.com working fine.
However the problem is in my naked domain. Whenever a http request goes to http://example.com/, it gets redirected to http://www.example.com/, ok. But, if a http request goes to e.g. http://example.com/a.html, the request is still redirected to http://www.example.com/. So when LE servers come looking for their well-known acme-challenge, it fails because they see index.html.
I guess this isn't a common behavior because no one is mentioning this, not at https://code.google.com/p/googleappengine/issues/detail?id=10802, nor at https://github.com/certbot/certbot/issues/1480.
I've tried to dig into why this is happening, one error I can see is here:
If I select to overwrite, GAE says it "failed to insert mapping"
This whole project was started by another person and he claims he's not aware of example.com being assigned anywhere else. I've looked at his Google Cloud Console and it would seem that he's correct.
Maybe something of interest is that in the Domain page of admin.google.com, naked domain redirect is set up. It redirects example.com to www.example.com. I've not found a way to disable it.
On my dns registrar, I have input the four A records, four AAAA records, and a www for CNAME.
TL;DR: My LetsEncrypt acme-challenge is failing for my naked domain, help!
I started getting the same error in app_engine after I went to Google Apps account and added example.com to redirect to wwww.example.com. After I did this, in app_engine I got "is already mapped" error. And there was no way to undo the redirect in Google Apps, so my guess was that Google Apps had mapped it and so App Engine could not modify it or add it. I had to explain this to Support team, and btw Google Apps support is free to call, so contact them and then get transferred to App Engine support team.
There is no way to fix it yourself, you have to get Google Support on call and explain clearly and they can reset. I was bounced between Google Cloud and Google Suites (Apps) support teams 7 times and after 2 weeks finally resolved, each one blaming the other, until I found a guy who understood this issue and fixed it for me.
We are starting a very large web based service project. We are trying to decide what hosting environment to use. We would really like to use Google App Engine for scalability reasons and to eliminate the need to deal with servers ourselves.
Secure logins/registrations is very important to us, as well as using our own domain. Our target audience is not very computer savvy. For this reason, we don't want to have the users have to sign up with OpenID as this can't be done within our site. We also do not want to force our customers to sign up with Google.
As far as I can see, I am out of luck. I am hoping to have a definite answer to this question. Can I have an encrypted login to our site accessed via our domain, without having to send the customers to another site for the login (OpenID/Google).
Thanks.
The hardest part is getting around the cookie issue. While you can do secure and custom logins against https://yourdomain.appspot.com, you cannot set a cookie there that will work on http://yourdomain.com.
Here is what I propose:
When you need to log the user in, send them to https://yourdomain.appspot.com. If they enter the credentials properly, create a one-time token and place it either in the datastore or in memcache. Give it a lifetime of a few seconds.
Then redirect the user back to http://yourdomain.com/authenticate?token=mytoken (obviously substitute the names as appropriate), check to make sure that the token is valid and has not expired, and if all is clear, set the appropriate cookies and expire the token.
I think that'd work just fine. Hope it helps!
As of June 27, 2012, App Engine supports SSL for custom domains.
http://googleappengine.blogspot.com/2012/06/google-app-engine-170-released-at.html
There is nothing stopping you from creating your own authentication/registration mechanism with Google App Engine. The only problem is that Google App Engine currently only supports HTTPS via https://yourid.appspot.com and not your Google Apps Domain (i.e. https://www.foobar.com). However, this is on the product roadmap for future support (SSL for third-party domains). Note, also on the product roadmap is built-in support for OAuth & OpenID.
Update: Another option may be to use a proxy server (like Apache with mod_proxy) and map your domain to the proxy server and then the proxy server can proxy the HTTP and HTTPS requests to Google App Engine. The requests could be proxied to the appspot.com domain behind the scenes. I haven't actually done this, but I believe it should work. However, this would give you a single point of failure at the proxy server which basically defeats the purpose of Google App Engine's high-availability and scalability. This would definitely just be a short-term solution until Google supports SSL for third-party domains or OpenID.
Depending on whether your threat model can accept a non-encrypted link on the "last hop" to GAE, you can use a proxy to handle SSL from the browser. Here's a HOWTO I wrote up on using CloudFlare to get always-on SSL:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine
This isn't structurally any different than the way SSL from Google will work, it's just that Google-provided SSL will terminate within G's network rather than just outside it. If you're trying to protect against Firesheep, CloudFlare (or any other SSL proxy) will do fine. If you're worried about snoops on the trunk connection between CF and Google, you may want a more sophisticated solution.
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
Since App Engine is so locked down I assume there is no way to setup an SSL certificate to allow credit card payments. In the absence of this, how is it possible to secure handle payments in an App Engine app?
http://code.google.com/appengine/docs/java/config/webxml.html#Secure_URLs says that
<ssl-enabled>true</ssl-enabled>
can be set in your appengine-web.xml file with *.appspot.com subdommains. Google had a typo in their opening tag on that page, just FYI.
For Google Apps you can't use HTTPS at all, but for appspot you can.
As far as using your own cert, you can't! For appspot, Google's cert is
not signed for your web-app's specific domain so it will cause a browser pop-up, but if accepted the page will load.
As of today, App Engine supports SSL on your own domain. See:
https://developers.google.com/appengine/docs/ssl
Note that there are two options. The more expensive (VIP - $99 per month) will work with all browsers, whereas the cheaper (SNI - $9 per month) doesn't work on some variations. See here:
http://en.wikipedia.org/wiki/Server_Name_Indication#Support
You can also use e.g. Cloudflare.com to front your app and provide SSL. Currently this is HTTPS to Cloudflare and then normal HTTP to App Engine. This will protect from any drive-by hacks but would be possible to intercept should an attacker somehow get between CF and GAE. This technique is described here:
http://blorn.com/post/20185054195/ssl-for-your-domain-on-google-app-engine