I'm using Parse to login users with Facebook (on ios, using the Facebook and Parse ios SDKs).
I always assumed that the Facebook SDK was using the latest version of the API by default, meaning that Parse would probably do the same.
However, if I check the Facebook tokens stored by Parse in the authData field using the Facebook Access Token Debugger (https://developers.facebook.com/tools/debug/accesstoken), it seems that my tokens are generated by a call to API v1.0.
In the User ID field, it says 'User last installed this app via API v1.0'.
Also, the Scopes field contains permissions that I didn't request (like basic_info, user_location, user_friends)
Anyone knows why ? Is this normal ? Any chances that my app will break on april 30 ?
Thanks !
Update : This actually seems to be random. Some tokens have the User ID field that says 'User last installed this app via API v1.0', and some others have 'User last installed this app via API v2.x'. And they are all users who signed up today, with the latest version of my app !
Using Parse with Facebook login for iOS and Android won't require any changes, and your app won't break on 4/30. We're upgrading our side of things and will be using v2.3 shortly.
Related
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!
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.)
My app is now using the Facebook SDK version 3.1.1 for iOS.
On iOS6 I'm noticing strange behavior with the FBSession expirationDate. The date is always set to the year 4001 (distant future?). I've read that this can be related to offline_access permission but we're not asking for that (we did at one time, in a very old version of the app. But this is a fresh install on a clean image.)
Per the FB SDK guidelines we always ask for basic read permissions first via FBSession openActiveSessionWithReadPermissions. The session expiration date returned is always 4001-01-01. Later, when we want to post, we call FBSession reauthorizeWithPublishPermissions, asking for publish_action.
This all seems to work fine until the token expires. I only noticed the expirationDate issue because I found that we were passing expired tokens to the graph API, and those calls were failing.
But this shouldn't happen, right? - whenever the app starts cold we're calling FBSession openActiveSessionWithReadPermissions, and whenever the app becomes active we call FBSession handleDidBecomeActive. This should be correct to refresh any expired active token, yes?
What am I likely doing wrong, and what are some things to check? And why is the expirationDate set to 4001?
Edit:
I think my issue is related to what is described here: Expired access token after openActiveSession for Facebook iOS SDK
I'm not using any of the FB SDK support for calling the graph API's. So I'm not taking advantage of the apparently built-in SDK support for refreshing the iOS6-managed token.
Edit 2:
I think this is an exact duplicate of my issue:
iOS 6 Facebook Login not refreshing access token
also referenced here: http://developers.facebook.com/bugs/441739699216684?browse=search_5099512da57214b73000801
The offline_access permission did in fact return an auth token that expired in the year 4001.
In my experience so far, iOS 6's native FB auth always returns a token whose expiration date is recorded (in your app's plist) as the year 4001 as well, but whose actual expiration date is much different, according to the FB token debugger. In short, don't rely on the value stored on the phone. Somehow there's a disconnect.
I too had the same assumptions as you did (calling FBSession openActive... and handleDidBecomeActive) about my token getting refreshed by calling those methods, but that didn't pan out for me either.
In your updates, you linked to a similar question I posed, and I just added my solution. You can check it out here:
http://facebook.stackoverflow.com/questions/13125430/ios-6-facebook-login-not-refreshing-access-token#answer-13298770
Hopefully this helps!
I try to get the signed request to login the user via a webservice but I only have access to the accessToken on FBSession.
I saw this link
Facebook Signed Request for iOS (HMAC SHA256)
who shows how to convert the signed_request but doesn't show how to get it.
Need help :)
If I undersand you right you want your app to login and then make a call to a server where you need to check the users credential again.
I used this tutorial for the authentication.
Then when I call the server I send the accessToken property as a parameter to check the users credentials on the server. You can get the token value like this:
FBSession.activeSession.accessToken
On the server side you can then set the access token to the value you got from the app.
I compiled a gist that generates a signed request which you can then use to authenticate a user on your server without having to query the graph API.
You can find it here: https://gist.github.com/3962188
You can find the original question I compiled it for here: Facebook iOS SDK to return a signed request object upon login
Please note that most of the code is simply a compilation of existing open source code, but I haven't seen any fully working implementation like this anywhere.