16

When create a Google API Oauth2.0 Credentials on Google Developers Console, I choose "Web Application" Application type.

In the "Authorized redirect URIs" field, I can use http://127.0.0.1/callback, it work fine for me on local development.

but when I want to use Google API Oauth2.0 Credentials on my server(let's say 99.99.99.99), I have to use http://99.99.99.99/callback as my "Authorized redirect URIs", but google give me a warning:

Invalid Redirect: http://99.99.99.99/callback must end with a public top-level domain (such as .com or .org)

Except to bind a public top-level domain to my server, what else can I do?

I develop in Django and use oauth2client to deal with Google API Oauth2 , So there are two table "oauth2_authentication_credential", "oauth2_authentication_flowmodel" in my database which have the credential value in it, I copy them from my localhost to sever, but it doesn't work.

GoTop
  • 850
  • 1
  • 9
  • 22
  • 1
    If you can use fake domain for example: yourrealdomain-localhost.com. Add this domain to windows hosts file and make it looking for 127.0.0.1 So, you can enter this domain in Google dev console. – vee Dec 30 '17 at 16:04
  • @ vee your method look good. – GoTop Mar 22 '18 at 02:23

1 Answers1

24

There is help text near "Authorized redirect URIs" field, that clearly states that you cannot use public IP addresses:

Authorized redirect URIs

For use with requests from a web server. This is the path in your application that users are redirected to after they have authenticated with Google. The path will be appended with the authorization code for access. Must have a protocol. Cannot contain URL fragments or relative paths. Cannot be a public IP address.

127.0.0.1 is not public IP, but a loopback, that's why http://127.0.0.1/callback works fine. localhost also could be used: http://localhost/callback

Except to bind a public top-level domain to my server, what else can I do?

You can use free DNS by http://xip.io/. So for IP 99.99.99.99 use http://99.99.99.99.xip.io/callback. And it would be resolved to http://99.99.99.99/callback.

polart
  • 511
  • 6
  • 7
  • Thanks for the explanation of loopback and public IP. I try to visit http://99.99.99.99.xip.io (replayed 99.99.99.99 with my real server ip), then it return a page with the text "Welcome to nginx on Fedora!", this is not server page, is there something wrong? – GoTop Mar 20 '16 at 14:40
  • All that xip.io is doing is resolving hostnames (`99.99.99.99.xip.io` in that case) to IP addresses specified in that hostname and nothing more. "Welcome to nginx on Fedora!" is a nginx default landing page. Have you deployed your application to a server and configured it? Do you see your app at http://99.99.99.99? If your application is accessible at http://99.99.99.99, then http://99.99.99.99.xip.io should work fine. – polart Mar 20 '16 at 15:04
  • I use CentOS 7 and Nginx on my server. I can access my Django project at 99.99.99.99. According to You suggest, I found that the page with "Welcome to nginx on Fedora!" is my Ngnix's 404 page. But I get different page when I visit 99.99.99.99 and 99.99.99.99.xip.io , Maybe there is some misconfig on my Nginx config file? – GoTop Mar 20 '16 at 16:26
  • My guess is that in nginx config in server block for your app you have something like this: `server_name 99.99.99.99;`. If so, then change it to `server_name 99.99.99.99 99.99.99.99.xip.io;`. – polart Mar 20 '16 at 21:58
  • your guess is right. After I change server_name to 99.99.99.99 99.99.99.99.xip.io in ngnix.conf, 99.99.99.99.xip.io work just like 99.99.99.99. Thanks man, I have accept your answer for this question. – GoTop Mar 21 '16 at 08:41
  • 2
    There are reserved top level domains ( https://tools.ietf.org/html/rfc2606 ). So, Google should allowed these domain for local environment testing. This can make things a lot easier. How to let Google know? – vee Dec 30 '17 at 16:01
  • 1
    @vee - It's been a while, but I just opened this: https://issuetracker.google.com/issues/254199033 – Alexander Trauzzi Oct 18 '22 at 11:50