I'm building an iOS app that requires the user to authorize Google API's via Oauth2 using the server side web flow. I currently open a UIWebView to start the oauth2 flow.
This works fine in the simulator because I'm setting the redirect URI to http://localhost
and have a server running on my local machine.
However, I'd like to test on the device while still connecting to a server running on my desktop. In order to do this, I've gotten the app to discover my desktop address (a local subnet IP or bonjour address like http://foo.local.
) to connect to the server. However, the Google Oauth2 flow is saying that it cannot use local URI's as a redirect url.
Is there any way around this? I'd like to not have to mess with my local network setup or proxy requests from my IOS device if at all possible. I'd ideally also like to be able to use the bonjour service to discover the server because we have a team of developers and our app lets you choose which server on the local network you'd like to connect to.
Options?
CodePudding user response:
Updated 19/03/2013
If server is a must have middle man, then I recon the easiest way is to grab a domain name and make the server go public. www.godaddy.com or any domain name provider will get a domain name for about $15 per year (would be lower if there is discount).
After that then just search how to get a dynamic DNS and setup the redirect_uri as the domain name that has been choose.
Otherwise I didn't see the role of the server is playing here if only for the oauth purpose. As the second method listed below, a device can communicate to google server directly even behind a heavily defenced fire wall. (token will be passed throw the title bar).
So might need some clairification here.
Would the localhost server acting like a hub to cashing files from google drive and then redistribute to iOS devices? Or what kind of network architecture would like to achieve here?
==
Updated 18/03/2013
according to the official document https://developers.google.com/accounts/docs/OAuth2InstalledApp#choosingredirecturi
There are two ways of oauth. using localhost as redirect is just one way.
another is to use this string
urn:ietf:wg:oauth:2.0:oob
to replace the request where it have local host.
For example, a previous request with localhost of (note: the difference is on the middle line starting with 'redirect_uri=')
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile&
redirect_uri=http://localhost:9004&
response_type=code&client_id=812741506391-h38jh0j4fv0ce1krdkiq0hfvt6n5amrf.apps.googleusercontent.com
now can be changed to
https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile&
redirect_uri=urn:ietf:wg:oauth:2.0:oob&
response_type=code&client_id=812741506391-h38jh0j4fv0ce1krdkiq0hfvt6n5amrf.apps.googleusercontent.com
so access the url of the former one in the simulator should be equivalent of accessing the latter one in real device.
Halo
CodePudding user response:
Could you try this approach? Add the following to your /etc/hosts
file in your Mac OSX -
192.168.33.100 trialapp trialapp.com #put your local IP address instead of 192.168.33.100
Goto Google API console set up for your new Client ID and change the redirect URL to http://trialapp.com/
- "Application Type: Web Application".
- Via "Your site or hostname (more options)":
- In "Authorized Redirect URIs" enter http://trialapp.com/
- In "Authorized JavaScript Origins" enter http://trialapp.com/
What we are doing is mapping your local subnet IP address to a alias domain name. So Google should no longer think that this is a local address. See if this works?
CodePudding user response:
I ended up solving this by taking the following approach.
In my UIWebView, I intercepted all loading requests and modified the URL's. Basically, I set the redirect_uri to something public (that is also registered on the api console), but when the UIWebView tries to load that redirect URI (after several redirects), I rewrite that URL to instead point to a callback on my mac on the local network.
Obviously this needs to be taken into account when parsing the token on the server side.