In a deprecation announcement from Google, they say that developers need to migrate away from these scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
and instead use these scopes:
email
profile
After doing so on my App-Engine backend, however, I'm having problems with my iOS app. On first run, it asks me to sign in and the screen shows both scopes correctly after which the app runs just fine. On the second run, where it is supposed to retrieve the authorization credentials from protected storage, it does not work as the App-Engine server is receiving null for the User parameter in the endpoint.
The App-Engine endpoint requires both the email and profile scope. The iOS code for retrieving previous credentials is:
GTMOAuth2Authentication* auth =
[GTMOAuth2ViewControllerTouch authForGoogleFromKeychainForName:AUTH_KEYCHAIN_NAME
clientID:Constants.IOS_CLIENT_ID
clientSecret:Constants.IOS_CLIENT_SECRET];
and the iOS code for authenticating should there be no previous credentials is:
viewController = [[GTMOAuth2ViewControllerTouch alloc]
initWithScope:Constants.EMAIL_SCOPE
clientID:Constants.IOS_CLIENT_ID
clientSecret:Constants.IOS_CLIENT_SECRET
keychainItemName:AUTH_KEYCHAIN_NAME
delegate:self
finishedSelector:#selector(viewController:finishedWithAuth:error:)];
This used to work just fine! Now the App-Engine server changed the email scope from .../userinfo.email to email and the profile scope from .../userinfo.profile to profile. The iPad app exhibits the same behavior against the new backend with Constants.EMAIL_SCOPE set to either value.
The google-api-objectivec-client library is v0510, the latest.
The Android version of my app continues to work just fine without any code changes after the backend change.
Update 2015-02-26: Now using r424 (2014-12-30) of google-api-objectivec-client. No change. If the AppEngine backend is using the new "profile" and "email" scopes, the iOS app cannot authenticate on the second (or later) run where it is loading the credentials from store rather than going through the sign-in flow.
The AppEngine log of the first (sign-in credentials) shows:
com.google.api.server.spi.auth.GoogleIdTokenUtils getCurrentUser: getCurrentUser: IdToken; email=testuser#gmail.com
The AppEngine log of the second (loaded credentials) shows:
com.google.api.server.spi.auth.AppEngineAuthUtils getCurrentUser: getCurrentUser: AccessToken; Tried and failed to get client id for scope 'com.google.api.server.spi.config.scope.DisjunctAuthScopeExpression#a015b54e'
com.google.appengine.api.oauth.InvalidOAuthParametersException:
at com.google.appengine.api.oauth.OAuthServiceImpl.makeSyncCall(OAuthServiceImpl.java:139)
at com.google.appengine.api.oauth.OAuthServiceImpl.getGetOAuthUserResponse(OAuthServiceImpl.java:118)
at com.google.appengine.api.oauth.OAuthServiceImpl.getAuthorizedScopes(OAuthServiceImpl.java:90)
at com.google.api.server.spi.auth.AppEngineAuthUtils.getOAuth2AuthorizedScopes(AppEngineAuthUtils.java:140)
at com.google.api.server.spi.auth.AppEngineAuthUtils.getCurrentUser(AppEngineAuthUtils.java:89)
...
This exception does not propagate up; null is returned for the user.
Is there something else that needs to be done for the GTMOAuth2ViewControllerTouch to work correctly with the new scopes? Or is there perhaps something wrong on the AppEngine side?
Related
In our app we are using the Google Drive REST API. To authenticate, we're using Xamarin.Auth with the following configuration
var authenticator = new OAuth2Authenticator(<our client ID>,
null,
"https://www.googleapis.com/auth/drive",
"https://accounts.google.com/o/oauth2/v2/auth",
<our redirect url>,
"https://www.googleapis.com/oauth2/v4/token",
null,
true);
The login is presented using
var loginPresenter = new OAuthLoginPresenter();
loginPresenter.Login(authenticator);
(this is not the actual code, since the authorization is encapsulated in a class and the authenticator and the presenter are injected, but basically this is what we're doing).
This will open a login form in a browser and allow the user to login, resulting in the form calling back our app with a OAuth2 token. Everything works like a charm.
Our client ID has been created using the hash of our debug keystore. According to the docs and other questions (see here and here), this should cease to work in release configurations when the app is signed with a different keystore. Anyway, having signed the app with our internal testing AdHoc keystore, the login form still works without any issues. Actually I do not see how it should not. After all, all we do is opening a website in a system browser control, hence I do not understand how the website is supposed to get our apps hash.
Since the linked questions lack details, I can't see how they are different to our situation, but I somehow assumed Google OAuth to do some black magic to ensure that the hash matches. Is there any reason that this works for us? Can we expect it to keep working after it's been uploaded to Google Play or is there any risk that it stops working?
Ive previously requested public_profile, user_friends, and email which Facebook will let you use pretty freely in my Swift iOS app but now I'm trying to update the app to request new permissions with loginWithReadPermissions but when it transfers to the login page it just says that I've already granted my app permission and doesn't request the new permissions. Querying the results shows no granted or denied permissions and looking at the Graph Explorer API on the Facebook Developer site shows the same. So I'm looking for suggestions on why my app might not be sending the updated request to the server.
I should note that I'm utilizing the AWS iOS Mobile SDK. I found another answer that overwrites the default Facebook sign in provider to add new permissions to the request but this has the same result.
Also in my output Im seeing the following string which contains all the permissions Im trying to request which makes me think that the request is going out but something else is happening
scope=email%2Cuser_birthday%2Cuser_hometown%2Cuser_friends%2Cpublic_profile%2Cuser_about_me
I am very confused by the BC documentation on their API, because they let you create "Draft Apps" (private apps) and now I see that in their documentation they say "We do not currently provide a means of keeping OAuth apps private.".
My concern here is that they made some changes recently that might have affected a few of my Private Apps that I had running just fine a month ago. If anyone can provide some insight, I would appreciate it greatly!
https://developer.bigcommerce.com/api/guides/oauth-transition
There is nothing wrong with creating oAuth credentials with a "Draft App" for the sole purpose of accessing the API of your store. You do not ever have to publish your app and your app will never be made "public" in that case. You also don't have to bother with the 'Load Callback URL' and filling out the details on your draft app, unless you want to provide yourself an interface in the store.
The "Draft App" function was specifically meant to allow Developers building apps for the BC App Marketplace to test their apps in a store before submission. However, you can use it to make a private application that is only intended for your store - I'm including the process here for others!
Making a Private App with oAuth (or How to Generate oAuth Credentials for a Store)
What you will need
Access to the account listed as the "store owner" of the store where you want to install your app or the ability to get a person with access to complete a couple steps
Ability to setup a local or public URL to receive the 'Auth Callback Request'
Getting started
The first thing you should do is sort out making available a local or public URL that can receive an "Auth Callback" request. This resource must be able to work over an HTTPS connection but the SSL can be self-signed. The 'Auth Callback' request from Bigcommerce is a GET request that will have 3 query parameters on the URL: code, scope, and context.
It is described in greater detail here:
https://developer.bigcommerce.com/api/callback#get-req
Additional info
When building a public app it is important that the service receiving the Auth Callback request be configured to catch the 3 query values and combine them with information you already have. You would then send all of this information in a POST to the BC oAuth Token service to generate your API token for the store. In addition to that you would want to respond to the Auth Callback request with a 200 status and an interface, or instructions, for the user.
In the context of building a private application you don't need to worry about any of that. All you need to do is capture the query values. If you have this already then go ahead and jump down to the section on generating an API token below.
Before Moving On
You should have a URL path that can receive a GET request and captures query parameters. Test it out and make sure it works. Here are a couple example URLs:
https://example.com/auth-callback
https://localhost:8000/auth-service
Registering an App
The key point here is that the registration of the app must be completed by the store owner account of the store where you want to install the app. If you have access to the store owner account credentials then follow the steps at the bottom of this page:
https://developer.bigcommerce.com/api/registration
If you are working with the store owner then you can direct them to complete the steps above. You will need to provide them the Auth Callback URL you created for completing Step 9. The Load Callback URL does have to be filled in but the default example provided can be left in place.
SCOPES
When registering an app you are able to choose the scopes for the app. It is simple to just leave them all open but it is best practice to only enable the scopes you need. Here is a list of the scopes:
https://developer.bigcommerce.com/api/scopes
If you are not sure whether or not you will need a certain scope then leave it enabled because you will have to re-generate your API Token (perform a re-install of the app) if you have to change the scopes on your app.
Before Moving On
You need to have the client_id and client_secret. If someone else registered the app then you will need to ask them for this. There is a View Client ID button that will provide it after registering an app.
Generate the Auth Callback Request
You will need the person with store owner access again for this step. They will need to login to their store and go to the Apps section on the left side column. After that click on Marketplace -> then My Apps (in the top-right) -> then My Draft Apps
You should now see a list containing any "apps" that the store owner has registered. Choose the one relating to the client_id you plan to use. Click to install the app.
The Auth Callback request has now been sent and you are done here. You should expect to see just a blank or grey page as a result unless you are responding to the Auth Callback request with content. Your app is now awaiting authentication.
If using a self-signed certificate
When your Auth Callback URL has a self-signed certificate then you will see a "untrusted cert" error in your browser when you attempt installation of the app. You should choose to trust the certificate and continue.
Before Moving On
You should now have received the code, scope, and context at your Auth Callback URL. If you did not it was likely due to not having SSL/TLS at your server. You can replay the Auth Callback request as many times as needed by Cancelling Installation of the app in the same place where you started it. You can even open up a Dev tool and watch the request happen to see what errors show up in the console. If this is continuing to fail then you should reach out to Bigcommerce support or ask a new question on here!
Generating an API Token to Complete Installation
Follow the steps here:
https://developer.bigcommerce.com/api/callback#post-req
You should have all of the details needed to send a POST request to the BC Auth Token Service at https://login.bigcommerce.com/oauth2/token
Make sure to URL encode your content and you should be good! Here is a site that can URL encode and decode for you: http://meyerweb.com/eric/tools/dencoder/
Just be careful of it encoding & and = signs when those are actually being used as separators between fields or between field/value (respectively).
Before Moving On
You should have received a successful response from the Auth service which will include your API Token. Once you have this you are all set to access the API of the store. You no longer need to have your Auth Callback URL up and available and can take that down.
Also take note of the context to use to create your API path.
Accessing the API
Now that you have your API Token and context you are all set to access the API of a store. Start off with a simple request to the /time endpoint.
Make a GET request and include the following headers (minus the curly braces):
X-Auth-Client: {CLIENT_ID}
X-Auth-Token: {API_TOKEN}
Accept: application/json
Content-Type: application/json
Send your request to a URL path of (minus curly braces):
https://api.bigcommerce.com/{context}/v2/time
If you get back a 200 response then you are all set!
Additional Notes - Ways to Break Credentials
Once you have successfully generated an API Token for a certain app, that app will display in the Control Panel as an icon in the Apps section. The fact the app is there shows it is installed and allowing access. If you uninstall that app then the previously generated API token will stop working.
Changing the scopes on an already installed app will require it to be re-installed to correct the token.
Changing the store owner email on the store will cause the token to stop working. The API Token is specifically tied to the store owner that registered the app.
if you have apps in "My draft apps" and you used basic oauth, you will have to change to Oauth Authentication, but if only have private apps using "legacy api account", you will not need to change.
When logging in via Google (through Asana Connect from iOS App) the following error gets presented in the browser window: 'invalid_request: The required parameter 'redirect_uri' is missing.'
Logging in via username and password works absolutely fine.
Is that an issue at my end or within the Asana Connect API ?
Any idea how to fix this issue ?
A very interesting thing though ... when going back to the app and logging in again, the authentication happens successfully without asking for user credentials, returning to the app with valid accessToken & refreshToken.
I too use GTMOAuth for mac. This error occurs because in a normal web browser when we click login with google account, a new browser window opens to get credentials. using GTMOAuth it embeds only a single webview and so its unable to present a new browser window for google credentials to be used.
I am new to developing a Salesforce app and I am using OAuth 1 for authentication.
I am able to generate the Request Token, and I re-direct the user to the salesforce site.
Once I enter my credentials, I get a
Remote Access Authorization Error
There was a problem in setting up your remote access
with
oauth_error_code=1800
In my Login History page, it shows Status as Success for Application type OAuth.
I don't get any entry in my Debug Logs page.
I have enabled Development Mode.
Any ideas whats wrong?
So https://login.salesforce.com/services/oauth2/success is a stub URL for callbacks - and that is the screen you are seeing there, and the access_token variable is your session ID for the user. So the OAuth flow is working correctly.
In the code, you might check to see if oauthResponse.access_token is getting set correctly. If so, it looks like:
sfw.login( setupHomeView );
That is what should tell it to move from that page to the next UI page.
You might also check out the Force.com Mobile SDK (link). It also includes PhoneGap and has a great OAuth wrapper built in.