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.)
Related
I'm working on a cross-platform app (iOS & web) that uses Parse server (and Parse iOS SDK on iOS). When switching between the iOS app and the web app, I get an "invalid session token" error that prevents any further calls to Parse from succeeding. In other words, here are the steps that lead to this error:
Sign up for an account on iOS
Send the app into the background (does not log you out)
Open the web app in a browser and log in
Either close the tab/browser or log out, it doesn't matter
Open the iOS app, and an invalid session token error will occur when trying to make any calls to Parse
The same thing happens in reverse as well, so if you starting sign-up on the web, then log in on iOS, then back to web again, calls to Parse will fail for the web app.
I can see that when logging in (or signing up) on one platform creates an entry in the Sessions table, and then logging in on another platform will replace that entry with a new one for that user. Then when returning to the other platform, the Session entry will be different (with a different token) causing the error.
What is the best way to deal with this? Do sessions need to be managed manually in such a case? Of course, I could just pop up an error for the user to inform them that their session has expired and has to log in again, but it would be much nicer not to do that.
So does each platform need its own Session or is there a way to share sessions?
I'm currently using Parse iOS SDK 1.14.4 with Parse Server 2.3.7. And in the iOS app, I am calling enableRevocableSessionInBackground().
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'
Context
I use booth Cognito User Pools and Cognito Identity Pools to sign-in user.
I want to achieve the simple task to sign-in a user on a iOS app, a Swift app.
My app is based on custom version of Mobile Hub Help to allow the use of Cognito User Pools. See A Swift Sample Sign-In App (using aws-mobile hub-helper) with Cognito User Pools
There is two steps in app: first one is only launch and second one is Sign-In after user touch a Sign-In button: user credentials are then hardcoded for sake of minimality.
During the first step, user have to received an unauthorized identityId. Then after second step, user received an auth identityId.
Behavior
Before press signin, step 1, there is 2 requests to AWS:
AWSCognitoIdentityService.GetId
AWSCognitoIdentityService.GetCredentialsForIdentity
After press signing there are 3 more requests:
AWSCognitoIdentityProviderService.InitiateAuth
AWSCognitoIdentityProviderService.RespondToAuthChallenge
AWSCognitoIdentityService.GetId
Before request 5 — AWSCognitoIdentityService.GetId — user is signed-in, as indicated by observer on AWSIdentityManagerDidSignInNotification.
After request 5, an IdentityId is retrieved. But immediately after user is signed-out according to observer on notification AWSIdentityManagerDidSignOutNotification.
What may happen?
It would help to have a look at your logs. But what you need to realize is that cognito sdk REMEMBERS stuff (session id's, identity id's, etc) using keychain and NSUserDefaults. So when you run your hard coded test for a second time, the behavior of your test will probably be different. If you want to start clean, go to the simulator menu and choose reset content and settings (this will clear out the keychain - which stores session stuff, and will clear out the NSUserDefaults which stores sessions that are active).
I just pushed a new version of the repo on the branch AddAllMobileHubDemos. The latest version of the repository has 3 targets defined. SignIn, MySampleApp and Dom. SignIn is a version of my old signin app modified to work with mobile-hub-helper. MySampleApp is a full downloaded MobileHub app with Cognito User Pools built in. There is also Dom, a single page hard coded signin app.
Also check out (in that same repository) the cognito-diagram cognito-diagram.pdf from the latest push, which has some of the possible errors listed. That version has the features I described above.
If you post the logs that might help me be more specific. There are cases where the AWSIdentityManager will log you out (for instance if you try to merge two identities... which you might very well if you are using a hard coded usrname and password and then changed them without ever logging out.)
Bruce
Problem solved!
#Bruce0 led me to answer!
First, on a real device running everything worked as expected.
Second, there were a lot of errors on log:
OSStatus error: [-34018] Security error has occurred.
The answer was to set the "Keychain Sharing" capability to "ON" in "Target->Capabilities" on Xcode.
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
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!