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!
Related
In the sparse Apple StoreKit Docs it mentions using a clientToken to request a personalizationToken from a device via requestPersonalizationToken.
There is no accompanying documentation to describe what this token should be. I had assumed that it should take the form of a developer JWT token but that does not appear to work, giving the error SKErrorDomain code 8 with a nil token response.
I know that the token works for a regular call to the Music API and so assume it is of the correct format for a developerToken.
I am aware that Apple are not giving out tokens via requestUserTokenForDeveloperToken until later in the year but assumed that requestPersonalizationToken was the current (although already deprecated) method until iOS 11 is released.
Apple Music sample code is using "requestPersonalizationToken forClientToken" for pre iOS 11 devices. The sample is passing MusicKit developerToken in JWT form for client token.
For any others that hit this thread.
Yes, the token is the same format. Apple have recently pushed an update out that resolves the issues that I was encountering. The exact same code now successfully retrieves a UserToken.
I have been using oauth 2.0 with Linkedin as the provider. Now as of today suddenly the authentication is no longer working. Looked on Linkedin its API profile page and figured that they have been updating their program.
The error that I am getting is the following:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.
This is in JS in the Console. I am wondering if this is the actual error or if there is another error.
I am using Rails on the back-end
LinkedIn February 12th 2015 update effects LinkedIn applications between May 12th - May 19th, 2015. Maybe, your application affected today.
I'm getting error after updating. Your application has not been authorized for the scope "r_fullprofile". The update affected somethings.
https://developer.linkedin.com/support/developer-program-transition
Figured it out! Not only on linkedin side, but also in your initializers you have to be careful with what you are asking for. So r_fullprofile is not longer part of Linkedin API (you have to ask linkedin to be able to make it work). There are also other API things that no longer work (e.g. r_connections), so be really careful as Linkedin has changed this policy.
In addition, you should not forget to reset the server to reinitialize the initializers.
A significant number of users are getting the error message of 'GetAccessToken - Unauthorized error: Your network is not allowed to request an OAuth token for this Application' whilst trying to log in to our application.
I have checked and tested, and they are accessing the correct network with the right credentials. This is happening to almost every person, so I don't believe this to be a coincidence.
This has only begun to happen in the past 24-36 hours. Are there any suggestions as to why this error is occurring, has something changed that I may have missed?
Thanks!
Couple of possible scenarios:
It is likely that the new simplified SSO is rolling out for these
users, which means they will use their O365 credentials to login to
Yammer from now on. Every user will need to reauth external apps (I
had to for our own apps also when this change occurred for us last
week).
Tokens also can expire when user's passwords expire, so if
they have a mandatory time interval to reset this could trigger an en masse need to reauth
Make sure your JS Origins are specified in your app details if you are using the Login with Yammer button and/or the JS SDK. http://naomimoneypenny.com/2015/02/11/yammer-apps-javascript-origins-update/
There isn't clear and definitive guidance regrettably from Yammer as to why and when tokens expire. Just that they do e.g. from https://developer.yammer.com/v1.0/docs/oauth-2
Once the token expires, you will need to re-run the steps above to generate a new code and access_token.
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.)
I randomly get the following message when trying to access the graph from my iPhone using Facebook iOS SDK:
response string: {"error":{"type":"OAuthException","message":"Error validating access token: The session was invalidated explicitly using an API call."}}
I'm not sure why this is because I call the graph immediately after I login, so the token should be valid. Also, this happens randomly around 30% of the time. Does anyone know how to go about debugging this issue?
I've been experiencing the same issue. It happens with any graph request after calling authorize immediately after a successful logout callback (with the idea being that a different user can log in from there).
The authorization screen will say that the user's already accepted the permissions (even though they're supposed to be logged out now...) and if they hit ok it will cause the issue. Almost as if the auth process reissues an invalidated token because it doesn't get the memo that they've logged out. However it won't happen if the user hits the "not you?" link and logs in as someone else as intended (or if they log in again as the same user), so this isn't a major issue in my case.
As for an answer / fix, I made mine fix itself by detecting the error response from the graph call and then making another call to authorize. Not ideal though, since it annoys the user with two consecutive app switches...