Im reading this google doc on how to hook up app engine to a custom domain (a domain I purchased through a different registrar)
I get to a point where I have to "Supply the domain name ("example.com") and click Verify. This opens up a new tab titled Webmaster Central." and walk through some prompts to prove I own the domain.
After doing this "domain verification is automatically re-confirmed about every 30 days".
What exactly is "domain verification"? Is there like a domain verification protocol that all DNS registrars must support? What communication is happening between google and say godady or AWS (route53)? Is there a special type of DNS record specifically for verification?
I don't understand whats actually happening to prove I own the domain and if this process is standardized or each DNS provider has their own solution/quirks for doing this.
From Verify your site ownership (also accessible via the Webmaster Central help menu):
What is verification?
Verification is the process of proving that you own the site or app
that you claim to own. We need to confirm ownership because once you
are verified for a site or app you have access to its private Google
Search data, and can affect how Google Search crawls it.
No, it's not a standard. Each hosting provider asking for it had their own method/algorithm of doing it.
Google actually has several such optional methods so that you can choose one that best works for your case. They're listed in the Verification methods chapter further down in the above-mentioned doc, together with some explanation of how each of them operates. Not all of them are based on DNS registrar actions.
Also keep in mind that Webmaster Central is used for other sites as well, not only for GAE-based sites - just in case some things might not make sense in a GAE context. This includes sites not even hosted on/using Google infrastructure/services.
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 Google Application Engine project that is working fine with two Custom Domains pointing at the application. mydomain.com and www.mydomain.com. I want to transfer the domain pointers to another GAE project on a second gmail account, and later transfer them back.
I thought this would be as simple as using www.google.com/webmasters/tools/ to make the second account a second owner of the two domains because they are automatically verified through delegation. This looks to be happening if I use webmaster tools with the second account, I see the sites as I do with the first account.
My plan was then to go into Custom Domains for the first account through https://console.developers.google.com/ and turn off the domains pointing to it and then go to the second account and point the domains to it.
Unfortunately whatever I seem to do I cannot get the other domains to show up in "2. Select the domain ..." I seem to need to verify the domains, even though delegation should be sufficient.
I could verify by hitting the domain registrar with new settings but it seems a pretty heavy approach when all I am trying to do is get Google to move the domain pointers from one GAE application to another.
Also there will be a long hiatus where the domains are pointing at nothing. I suspect this to be either my complete misunderstanding of the Custom Domain approach or a Google/GAE issue.
I suspect a Google/GAE issue because in the second account some of the descriptions of the delegated ownership domain names have http:// at the front and this is not true on the first account.
Any suggestions or help greatly appreciated.
I had this same issue, and I had to call Google Apps for Work (renamed from Business) to cancel the original account that housed the domain so it would show up in my second (new) account.
I have found a workaround/alternative which is to verify the domain names using the sub-domain method. I use 1&1 for my domain names and although it only allows 5 sub-domains I have a spare one I can use. So I have two sub-domains defined, one for each account as per verify settings in webmaster central. I can easily flip the domain pointer between the first and second accounts and back again using https://console.developers.google.com/ . This is partly because the other configuration settings that are necessary when you set up a domain pointer in Custom Domains are always the same for Google, even if the accounts and applications are different. There is no haitus with this method because the flipping takes effect immediately in Google, although the effect in the web world can take a while with caching occurring all over the place.
I could not used the suggested Google Apps/Business solution as I am not using either.
The conclusion I reach is that delegation of domain names is not really much use and best avoided.
I'm using Google's user api on Google App Engine for authentification. As nearly everyone have a Google Account and api is easy to implement, that solution is convenient.
The problem is, though, with user who do not have a Google Account (or have no idea what a Google Account is). Where the api provides a nice interface to log in/log out and redirect immediately and easily to the app, nothing is said to developers about potential new users.
So here are a couple of things worth noticing:
Google' new Google Account page (https://www.google.com/accounts/NewAccount) is pretty straightforward, but not convenient at all for new users of a GAE app: no mention of anything not Google (users who don't really know what authentification is won't have any clue of why they need to open an account with Google), dead end (won't lead anywhere in the end), ugly.
GAE Log In screen includes a link to the New Google Account page. This link is of the form:
https://www.google.com/accounts/NewAccount?continue=http%3A%2F%2Fexample.com%2F_ah%2Flogin%3Fcontinue%3Dhttp%3A%2F%2Fexample.com%2Fprofile%2F&service=ah<mpl=gm&sig=0aa0a000aa000a00000aa0000a000aa
(Where example.com is the return url provided to the API). Great! But the situation is in no way different than it was: still a dead end, still no mention of any non-Google app, still ugly).
So, I'm asking, is there any imaginative way to provide a nicer interface for new users? Have anyone have ideas of how to present the process to the new users (a video for how to create a new account? some kind of tutorial page? etc.)? Just trying to think outside of the technical box here...
Regarding the various authentication options you can check out the Java or Python docs on OpenID (http://openid.net/)
Basically this allows supporting authentication by different agents, which includes Google accounts or even your own GAE application's custom implementation.
Furthermore you can check out User Experience summary for Federated Login for more information regarding UX considerations and best practices - with user authentication.
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.
I've been fooling around with the Google App Engine for a few days and I have a little hobby application that I want to write and deploy.
However I'd like to set it up so that users are not directly accessing the app via appspot.com.
Is hosting it through Google Apps and then pointing it at my own domain the only way to go? I looked at that a little bit and it seemed like a pain to implement but maybe I'm just missing something.
My other thought was to write the app-engine piece as a more generic web-service.
Then I could have the user-facing piece be hosted anywhere, written in any language, and have it query the appspot.com url.
Anyone have any luck with the web-service approach?
The reason Google Apps is required is because you need somewhere to a) verify you own the domain (otherwise, you might point it at app engine, then I might hijack it by adding it to my account) and b) set up domain mappings (which subdomains point to which of your appengine apps).
Since this stuff already exists in Apps, it seems silly to duplicate it in AppEngine.
As has been pointed out, it doesn't cost anything, and you do not need to "move" anything to Google. You simple created a cname record with a random name to verify you own the domain, and a cname for the subdomain you wish to point at App Engine. This only takes a few minutes, and once it's done, it's done forever.
Note: If you host your site elsewhere and use webservices, you need to scale the site/frontend. If you host on app engine, you get this for free :-)
I wrote an article on my blog about redirecting *.appspot.com domains to your custom domain to keep your branding:
http://blog.dantup.com/2009/12/redirecting-requests-from-appid-appspot-com-to-a-custom-domain
To do this, I believe you need to be using Google Apps and have a custom domain setup for Google Apps. Then, you deploy your app into your Google Apps domain.
Here is google's official instructions on how to do that:
http://code.google.com/appengine/docs/domain.html
I have used this process for a couple of sites and it is easy and painless, provided you have control on the DNS records for your domain (you should).
OK, we're now at the end of 2017 and things are a lot different regarding App Engine and custom domains. It's easy now!
Go to the app engine dashboard for your app and choose Settings, then go to the Custom Domains tab. From there, choose Add custom domain.
The tricky part is that Google needs to verify that you control the domain, so they ask you to put a TXT record in the DNS for your domain. Once you do that and Google it, you become "verified" as the owner of the domain.
After that, Google will give you a bunch of A and AAAA (for IP6) records to put in your DNS. Once you've done that, you should be good to go.
It can be easily done using request.getRequestURI() method. If the URL doesn't include your domain, just redirect it to the desired URL using
resp.sendRedirect("<your domain>")
Otherwise load a error page using
request.getRequestDispatcher("<error-page>").forward(request, response);