I am working on collaborative web platform by ruby on rails and it's connected with facebook app (v2) by Koala gem..
When a user register by facebook account, there is facebook token (expire after 60 days)
The questions:
1- when and how renew the token in normal cases?
2- Can I renew token for 60 days again before end validity of the token?
3- Can I renew token automatically when user used his account in app with old session (without new sign in), or the user must sign out and sign in again to renew token?
I show this answer, but the tokens of users doesn't renew automatically when users visit to site with old sessions (without signin), do I have to finish their sessions automatically to force them to sign in again?
1 - When the user visits your App again
2 - Afaik you can only refresh them after the old one is not valid anymore. Not entirely sure about that though, as i have never tried.
3 - You can only renew the token with user interaction. if it would be possible to auto-renew, there would be no need for short- and long-living tokens at all.
Btw, renewal is very easy with the JavaScript SDK, by just calling FB.getLoginStatus on page load. In general, try to avoid using Tokens while the user is offline.
Related
My team have developed an App, in which we are using the Facebook Authentication Tokens to retrieve the data from a Facebook and then display it on our App and it is working fine.
The problem which I am facing is that if the Password of Facebook Account is changed then the API Token also become useless, which is an obvious thing.
But is it possible that when a user updates his/her Facebook Account Credentials then the API Token also gets updated? i.e. I don't want to go through the Token Generation Process, every time the password is changed.
No, that is not possible.
When the user changes their password, all their existing tokens get invalidated on purpose.
They will have to go through the login flow again, to create a new token.
According to the Facebook docs, mobile SDKs generate long lived tokens which are refreshed once per day when the person using your app makes a request to the Facebook servers. For the javascript SDK, short-lived tokens are generated and are refreshed periodically.
I'm curious as to what is meant by "the person using your app makes a request to the Facebook servers". Which calls specifically will cause the token to be refreshed? Or more importantly, which calls won't? Is it enough to check the login status or is something more active required? What I'm really interested in is keeping the token alive (or getting a new one) without sending the user back through the login flow, or doing anything that's particularly active with Facebooks APIs.
Thanks!
According to Facebook SDK Docu
Once a token expires ("auto" extend of Facebook SDK Token)
At any point, you can generate a new long-lived token by sending the person back to the login flow used by your web app - note that the person will not actually need to login again, they have already authorized your app, so they will immediately redirect back to your app from the login flow with a refreshed token
THERE IS no keep alive functionality in Facebook SDK.
User access tokens come in two forms: short-lived tokens and long-lived tokens. Short-lived tokens usually have a lifetime of about an hour or two, while long-lived tokens usually have a lifetime of about 60 days. You should not depend on these lifetimes remaining the same - the lifetime may change without warning or expire early. See more under handling errors.
long-lived = 60 days
Short-lived = 2 hour
Also according to Facebook SDK Docu
Mobile apps that use Facebook's mobile SDKs get long-lived tokens.
Once you force a user for a new oAuth/login, he will receive a new token. The old one will not expire. You are able to check the loginStatusby FB.getLoginStatus. No need for a keep alive.
The SDK will refresh the access token for you when an actual graph request is made (up to once a day). Any time the token is updated, the AccessTokenTracker will be notified, so you can register a tracker if you want to be notified of updates (e.g. for sending to the server).
If you only make graph requests from your server, then you'll need to handle expiration from there, and either try to extend, or prompt your user to do SSO again to get an updated token.
Our app already implements oAuth to obtain the access token and secret from Intuit, and all works well.
The app takes into account that users may have multiple QBO companies. Consequently, when a user tries to authorize access to one company, our app checks whether this company has been already authorized, and if it has, the app lets the user know so and does not try to re-authorize the company.
The way we implemented this is as follows. When the authorization process starts, we send or app the list of companies (realm ID) which have been authorized. The user clicks the "Connect to QuickBooks" button and follows the wizard. Internally the app gets the request token and it is ready to make the access token request. The request token request gets us the realm ID so we can compare it with the list of already authorized companies. If the company has been authorized we do not request the access token and let the user know that the company has already been authorized.
Up until a week ago this used to work -i.e. in this case, because the app does not make a request for the access token, the access token the app has is still valid. However, now something seems to have changed so that when the app makes gets the request token, even though it does not ask for the access token, the existing access token is not valid anymore and the user need to re-authorize the company again.
Has something changed in the oAuth flow implementation ?
Thanks
OAuth tokens are valid for 180 days(bydefault). So, please check if existing tokens are getting more than 180 days old. If so, please use 'reconnect api'.
Ref - https://developer.intuit.com/v2/docs/0050_quickbooks_api/0020_authentication_and_authorization/oauth_management_api#Reconnect
One suggestion -
You can implement SSO( using 'sign in with intuit' wizard) in you app. That way you can relate end-user's SSO URL with OAuth tokens of his company while persisting those in your app's db. For the very first time, end user will generate tokens through C2QB flow. Next time onwards whenever the end user will sign in, your app should retrieve his oauth tokens using his SSO identifier(your app should show 'Disconnect' option instead of C2QB if he already has an established connection).
Thanks
I've got my Javascript client app working well, but the streaming access token expires after 1 hour. I'm trying to make it play a playlist all the way through, which is often longer than 1 hour. Is there a way to renew the token without requiring the user to log in again?
Client-side applications cannot renew their token as they are not supplied with a refresh token. If you want to renew the token, you need to do a webservice application which can store a secret and use this to renew the access_token.
I'm implementing a connect with Facebook/Twitter/... functionality on a website. The idea is that once a user connects his account with the external services our website could post messages on behalf of the user.
With Twitter there is no problem as the OAuth access_token doesn't expire. But with FB it does expire every two months, when the user logouts, changes password or explictly deauthorizes the app.
How should I handle the token expiration? For me it would be ideal if I could refresh the token automatically without bothering the user, but unless I've missed something it seems there isn't any way of doing this. So, right now I've two ideas:
The less akward way: every time the user logins to the website check if the tokens have expired and notify the user that she has too reauthorize the app.
The more akward way: every time the "post to social networks" event triggers in our website, check if the tokens have expired and ask the user to reauthorize.
The first option would be easier to implement and cleaner to the user.
So, how are you handling this situations?
Thanks!
I think that I'll trye the first option:
User logs in
The server checks if the user has already a Facebook token, if so:
Check if it's still a valid token. http://developers.facebook.com/docs/howtos/login/debugging-access-tokens/
If the token expired NOT because the user deauthorized the app BUT because the other cases we redirect the user to the OAuth endpoint.
I'll give it a try and update this answer if there is more to it.
If the user is actually interacting with your website, you should be getting a fresh access_token (read below). If you perform offline tasks related to the user using the Facebook API then you should be storing the access_token and their expiry dates. Then you need to handle expired access tokens and ask the user to interact with your app again and update your records.
You should refer to this document. Also you should be reading the Extending Access Tokens document:
Step 2. Refreshing Long-lived User Access Tokens
At any point, you can generate a new long-lived token by repeating the
original auth flow, obtaining a new short-lived token and then
performing the same exchange as above. In some cases, this newer
long-lived token can be identical to the previous one, but we do not
guarantee this will be true and your app shouldn't depend upon it.