I have an iOS app that logs in to a Google Drive using the method outlined in the Google Quickstart page - iOS Quickstart
I have seen the message from Google about modernizing OAuth interactions
Authorisation requests in embedded browsers will be blocked on April 20 2017
I'm not using an embedded browser but I'm still getting this warning message. Can anyone confirm if this is a general message displayed for everyone, or does the fact that you're seeing the message indicate that it is relevant?
Do I need to change my access, and what happens if I keep trying to use this legacy method - does it simply fail?
I think that iOS Quickstart is outdated as far as the login part goes and that you'll need to use the new Google Sign-In procedure.
Google Sign-In for iOS:
https://developers.google.com/identity/sign-in/ios/start
This page had some useful info when learning about the process:
https://www.appcoda.com/google-sign-in-how-to/
A few other things I found useful for me:
1) .hasAuthInKeychain can be used to determine if a "silent" login should work
2) .currentUser of nil means you need to login through code, but user doesn't necessarily need to see login screen (if keychain auth exists)
3) After getting a .currentUser, you can use the old API code (at least for me) by assigning the authorizer as follows:
service.authorizer = [GIDSignIn sharedInstance].currentUser.authentication.fetcherAuthorizer;
Edit:
I've decided to switch to AppAuth instead of "Sign In". I'm using the following cocoapods which use the latest (I think, v3) Google API, along with AppAuth
pod 'GoogleAPIClientForREST'
pod 'GoogleAPIClientForREST/Drive'
pod 'GTMAppAuth'
Related
I am using OAuth2 for integrating Outlook Calendar APIs with my iOS app.I was following with this tutorial: Adding Calendar and Contacts APIs.
After the login UI, the presenting controller dismisses. Following that, while trying to implement any APIs (Calendar, Mail, etc), it shows this error:
OAuth2: No authorization context present
Anyone please help! I have been sitting for hours.
Look at this pull request: https://github.com/jasonjoh/swift-tutorial/pull/8
There was a change (either in XCode or p2.oauth2) since that tutorial was written. You need to use a different signature for your app delegate.
Our iphone app allows for sign in via Foursquare via oauth. It was working fine and recently stopped working.
The error we get is: Connecting Failure: Callback uri is not valid for this consumer.
HOWEVER, if the user does not have the foursquare app installed on their phone it works fine as before. It seems as if FS is now doing a redirect to handle the oauth inside the FS app and this fails when attempting to return to the originating application. Via safari it seems to work.
This is on ios 9.
Solutions?? Thanks!
We've changed to use a SafariViewController and this seems to force Foursquare to not to this strange in-app redirect, solving the issue. This is also Apple's preferred oauth method, so probably the way to go.
Still seems like a problem on the Foursquare side that they may want to address for others however. I'm closing this question. Thanks.
Where does your redirect URL point? If you want it to launch your app after completion you should point to the iTunes store (pre-iOS9) link for your app or the universal link (iOS9 onwards).
More information on redirects for the native foursquare app is available in the README here: https://github.com/foursquare/foursquare-ios-oauth/
How to create a universal link in iOS9 https://www.appsflyer.com/blog/how-to-set-up-ios-9-universal-links-for-your-app/
A callback url is a webpage loaded after your web app has been
verified. In this case, you need to specify a page for to send data to
after authentication
Double check your Foursquare credentials and update the callback uri to a valid link. Tutorial link
Please follow the below points, may be one resolves your issue:-
Enter the callback in foursquare account in addcallback methods. Then in your code add the call back to the provider before you authorize. (Reference here).
You're getting that error because the URL you're pointing your users to (foursquare.com/oauth2/...) includes a redirect_uri parameter that doesn't match with what you configured in your app's settings under https://foursquare.com/developers/apps. Make sure these match!
I am currently using the Salesforce.com IOS SDK Version 3.0 to build a native application that connects to salesforce. This app will be used for external users, so it is pointed at communities.
I first started by creating a Native IOS SDK app and getting that working and talking to salesforce.
I then created a new community, created a community user, gave them the proper permissions and finished setting up the community.
Next I went into the Xcode Project, under supporting files to the application plist. I then edited the SFDCOAuthLoginHost to be set to the community URL.
Once that was completed I restarted the app, and was able to login to the community through the native SDK and things would work great until the app hit its session timeout. At this point I receive these errors.
ERROR|SFNetworkOperation|callDelegateDidFailWithError Session expired or invalid
ERROR|SFNetworkOperation|Session timeout encountered. Requeue 0.000000or retry later
ERROR|SFNetworkEngine|Ignore session timeout error callback as host URL changed, request URL is https://dev-patientsupport-dev.cs21.force.com/dev/services/apexrest/patientNotifications, login host is [cs21.salesforce.com]
Of course because it cannot get a new session all web callouts fail after this point.
I have searched everywhere and cannot find a solution to this problem. My guess is that because the request is being made to the community URL, but the refreshed session is being sent from cs21.salesforce.com so it is being ignored. Thanks again for everyones time.
A fix for this bug has been submitted as part of Mobile SDK 3.1.1 patch on GitHub, npm (forceios), and Cocoapods. Please see https://plus.google.com/105428096535342044035/posts/AkoVwL5Kdt3 for more details.
It looks like this may be caused by the refresh token having its instanceURL set to the wrong destination when using communities. This may be a bug in the SDK as it works fine on the web. Try changing the instanceURL of the credentials to be the same as the URL of the community to see if that helps.
I'm attempting to integrate Gigya's social login into an iOS application. Within a ViewController, I'm triggering the showLoginUI method on the GSAPI class. This appears to work fine and invokes the web view containing links to each of the social providers. The problem that I'm facing is clicking on any of the providers, the delegate method gsLoginUIDidFail is returning the responseText
{"errorCode":400011,"errorMessage":"Invalid redirect_uri"}
I've been following the guide found at http://developers.gigya.com/035_Mobile_SDKs/010_iPhone
Initially, I thought that perhaps this was a problem with the gigya test providers, but adding a real provider app to the gigya configuration didn't resolve the problem.
The gigya api internally references a gsapi://login_result/ and wondered if perhaps this is the issue as I can't seem to work out where that protocol is being defined.
Also, running the test application linked in the guide encounters the same issue.
Hoping someone has encountered this problem themselves and knows what trick i'm missing to get things working?
Ok, so it turns out if you have already been using the API and have an API key, it's super easy to miss the step within "Gigya Setup - Obtain Your Gigya API Key" which requires you to tick a Enable Mobile or Desktop Client Applications API Access checkbox.
Ensuring this is set resolves the issue.
Background
Recently upgraded to Facebook SDK 3.2
Tested on both device and simulator (iOS 5.1 through 6.1)
Error is only present when attempting to authenticate Facebook test users.
Error
The Facebook server could not fulfill this access request: Temporarily unable to make API calls on behalf of XXXXXX.
UserInfo={com.facebook.sdk:ErrorLoginFailedReason=com.facebook.sdk:SystemLoginCancelled, com.facebook.sdk:ErrorInnerErrorKey=Error Domain=com.apple.accounts Code=7}
Steps to Reproduce
Clear simulator or manually remove Facebook account from device settings.
Create a test user via Facebook's accounts/test-users endpoint.
Add Facebook account in device settings.
Authenticate via openActiveSessionWithReadPermissions & accept the permissions dialog.
Expected Result
FBSessionStateHandler block returns with state == FBSessionStateOpen.
A nil NSError.
Actual Result
FBSessionStateHandler block returns with a error.fberrorCategory == FBErrorCategoryUserCancelled with the above user info trace.
Solution Attempts
I've followed the steps outlined in this question; namely checking my bundle name, ensuring my app type is set to Native/Desktop and setting my App Secret in Client to NO.
As well, I have ensured I am only asking for read permissions (ie. email).
I've even bypassed the Facebook SDK altogether by attempting to authentication with a ACAccountStore instance & got the same results.
Again, everything works fine with a regular user (non-test); so it must have something to do with the configuration & recent 3.2 changes.
1) Facebook 3.1 SDK splits read and publish permissions. Use only read permissions (e.g., email) in the first authentication call. Using both will break it and result in that generic error. It seems Facebook's SDK doesn't actually do what it's meant to do: fall back to older authentication methods. David tells me an updated Parse SDK will make the permissions split easier, but it will of course be up to Facebook to fix that bug in their SDK.
2) Independently, the issue I was having seems to have gone away after signing out of Facebook in the device's Settings, and then back in. Maybe a glitch in the iOS integration? (The permissions split issue still applies here, however. Make sure you do read first and publish (e.g., publish_actions) separately later, the first time you actually need it.)