When the member after closing browser or a few hour passed ,my member need to log-in to my website again, but the Facebook account still Logged-in.
I'm using Facebook PHP SDK, the latest version.
How can I do fix this problem without using Javascript SDK?
I just wanna keep the member log-in status as Facebook log-in status.
Extending Access Tokens since the removal of offline access, facebook offers an extension to the 2 hour tokens given by default.
refer to: https://developers.facebook.com/docs/howtos/login/extending-tokens/
deprecated
offline_access
Enables your app to perform authorized requests on behalf of the user at any time. By default, most access tokens expire after a short time period to ensure applications only make requests on behalf of the user when the are actively using the application. This permission makes the access token returned by our OAuth endpoint long-lived.
https://developers.facebook.com/docs/reference/api/permissions/#publishing
Using offline access should extend that login period.
i cannot say how long you users will stay logged in, but in my app at https://apps.facebook.com/anotherfeed i have been logged in for about 4 days now.
11.30.2011:11:14am
I was able to successfully logout with Javascript SDK with offline permission, but Failed to logout yet with PHP-SDK.
Related
How can one use Firebase Authentication to allow users to authenticate with a Google account via the C++ SDK (using it in Cocos2d-x).
I’m confused as to whether I would need to build a special Google auth GUI or if the SDK requires/contains a standardized GUI (or, in the case of Cocos2d-x, a Scene) that should be used.
Either way, I am unsure how to do it. Does anyone know how to proceed? The SDK example code shows how to authenticate via Email/Password but not via a Google Account.
Ok, so this is complicated, but not because of Firebase.
Basically, if you want to use a Federated Logon, such as Facebook, Google, Twitter, then you will need to use their UI SDK built for whichever platform you are using. When you successfully login with one of these services, you will construct a Credential with the token that is returned from one of these services.
After you login with this credential, the Firebase Auth service will associate any account data with this federated logon. If you were previously using an anonymous login, then the account should be upgraded. If you have already logged in with another credential (email, phone number, alternative federeated logon) then you will need to do some logic to check if you need to merge or switch.
Firebase Auth can outlive the Federated Token. For example, the Facebook Login token expires or is revoked, your Firebase Auth backend might remain signed in. Vice versa your Facebook token might not expire, but your Firebase Auth might have been signed out. You will need to manage these states.
Here's an example. We want to use Facebook Login as our federated logon provider. We link the Facebook Login SDK for our platform as described in the Facebook Developer docs.
When we want to ask for Facebook login credentials, we use the FBSDKLoginManager .loginwithReadPermissions() to launch the login flow. This typically consists of launching either the Facebook App to confirm permissions for your app or the website (make sure you implement deep links properly as described in the Facebook documentation).
Eventually, the login will succeed or fail.
If it succeeds, Facebook will hand you a token which you can grab from [FBSDKAccessToken currentAccessToken].tokenString. This is what you would send to firebase::auth::FacebookAuthProvider::GetCredential
All of this is ASync and done on separate threads. You should use a concurrent queue to funnel these events to your main thread.
It is possible to use your own server and signup form, in which case you would build your own UI in game and then make secure server calls to your backend. There's a flow for getting a text message to validate a user, not something I would do for a game.
Given my app has been authorized once by the user, will it be able to get new access tokens without requiring the user to log in again?
If yes how can it be done? (preferably in Node.js)
All other answers I found seem to refer to old versions of the API.
No, User Access Tokens are valid for a very short time, and you can only extend them to 60 days. After that, the user MUST visit the App again. You can NEVER get User Tokens without user interaction. This was not even possible with older API versions. There was only an offline_access permission some years ago.
More information about Access Tokens:
https://developers.facebook.com/docs/facebook-login/access-tokens
http://www.devils-heaven.com/facebook-access-tokens/
The new API gives Facebook users more security control by allowing the apps provider to set the expiration of the token to the maximum of 60 days. So, as from I know, there is no way for the user to authorize the token just once and use it forever.
I have an application, that runs on server. On that server is background task, that will post status update on few social networks (Facebook, Twitter, G+). It must be completely server-side.
In Twitter API I'm able to use OAuth header to authorize API request. OAuth HTTP header uses consumer key, consumer secret, access token and access token secret to create the header. With this I'm able to post/update/delete tweets with no user interaction.
How can I do this for Facebook? I found a solution to obtain a long-lived access_token (2 months), but we don't want to regenerate access_token every 60 days. We want to use it for manage our Facebook page - post status updates, but completely server-side.
Am I able to do this for Facebook? Thanks for answers.
PS: I searched stackoverflow hundred-times but with no solution for my problem.
Thanks.
It is not possible for User Access Tokens (they can only be extended to 60 days and need to be refreshed by the user after that), but for posting to a Page you should use a Page Token anyway. An Extended Page Token is valid forever.
Here are some Links to help you get that Extended Page Token:
https://developers.facebook.com/docs/facebook-login/access-tokens/
http://www.devils-heaven.com/facebook-access-tokens/
http://www.devils-heaven.com/extended-page-access-tokens-curl/
A Page Token will post "as Page" btw, but that´s probably what you want. And auto-posting on user profiles is not really allowed anyway, every message has to be 100% user generated and every posting should get authorized by the user.
Pay attention to Access Tokens Expiration & Extentions.
The Page Access Token could be a good solution to only server side calls for testing and data analysis purposes.
Take your User Access Token from Graph API Tool
Extend your User Access Token
Call https://graph.facebook.com/v2.11/me/accounts with your user access token extended
*all calls are GET and this procedure does not use APP Access Token.
The situation is still unclear for me – After July 5th 2012, will desktop application be able to have access to Facebook data if user, associated with access token, logged out from Facebook?
Are talking here about TOTAL deletion of offline access AT ALL or just limitation for offline access by 60 days?
Document - https://developers.facebook.com/roadmap/offline-access-removal/ doesn’t give clear answer (IMHO). Quote: “Once the migration setting has been enabled, Desktop applications will automatically get user access_tokens returned that have the longer expiration time. However, there is no way to get a long-lived user access_token without having the user login to your app again.”
As of April 30 I’m able to request access token WITH ‘offline_access’ permission for desktop application (using URL: https://graph.facebook.com/oauth/authorize?client_id=APPLICATION_ID&redirect_uri=http://www.facebook.com/connect/login_success.html&scope=manage_pages,read_stream,publish_stream,offline_access
) . And everything work fine. Even if user logged out. In spite of “Remove offline_access permission” was enabled for the application.
Your answers will be very much appreciated.
Just completed a patch to accommodate these changes. At least in my experience, we were working within a web app where renewing the access tokens was as simple as changing everything over to the Javascript SDK and relying on the browser's login state. This seemed a much more logical approach than cross-checking a server-side saved long-expiry access token with every action to see if it was still good.
Essentially, what is going to happen for desktop implementations is the access tokens will be longer-lived by default, but still require the renewal at the end of the sixty day period. You should have logic in your app that will check that validity of the access token with facebook before taking action with it (or just try and fail with a prompt) and then prompt the user to login and revalidate if the access_token has expired. So long as this logic is in place the access tokens that expire will trigger re-validation.
If your app receives short-expiry access tokens...
If you would like to refresh a still valid long-lived access_token, you will have to get a new short-lived user access_token first and then call the same endpoint below. The returned access_token will have a fresh long-lived expiration time, however, the access_token itself may or may not be the same as the previously granted long-lived access_token.
Short-lived access tokens, the kind that only last for a session until logout, are going to need to be converted to the sixty-day, long-expiry access tokens using the endpoint documented in that article. Desktop apps configured to the new setting will receive these kind by default, but these will still need to be regenerated with a new login after 60 days.
I agree that this is a lot clumsier to implement, especially for desktop apps, but it is certainly a lot more secure from facebook's standpoint. If you start to think of the access token as a transient rather than permanent access credential and start changing your logic to check validity via curl or some other http post mechanism, rather than referencing your database, you'll have a much easier time with the adjustment. Don't allow your architecture to assume that the presence of a saved access token guarantees access, and be sure to cross check them over to the facebook endpoints and prompt for re-login where necessary.
Facebook has two flows for Authentication, client-side and server-side. When should each one be used?
Facebook docs: https://developers.facebook.com/docs/authentication/
Possibly related: What is the purpose of the implicit grant authorization type in OAuth 2?
Depending on your needs you can use one or the other or both. If you want calls to facebook to be processed before the user sees a certain page then use server side... however if you want to display partial information until the user has authenticated, use javascript authentication.
It boils down to this:
Javascript authentication can happen with-in a popup window and does not require a page reload you can also just perform a top.location.href redirect.
PHP authentication involves a redirect to an authentication page.
Also see this thread, in particular this response.
To add to #Lix's answer, I would say:
Client Side Authentication
When you want some information from Facebook API about the user that is required once, as in you only need to get it once like the user's name and email.
When you want to temporarily access/manage the user's information/data and don't need to do it often.
You get a temporary token, which is valid only for a few hours and you need to get a new token to call the Facebook API again after it has expired (which requires the user has to grant permission again).
Server Side Authentication
You want to manage the user's data (on their behalf) after the user has left your website/app. Example, gathering the user's feed/timeline data on a regular basis.
When you want to access/manage the user's information/data in a recurring fashion untill the user hasn't revoked access to your client id (represented by a Facebook app).
You get both a temporary token and a permanent token (which lasts for about 60 days at the time of writing this). You can get a new temporary token by using the permanent token every time you need to call the Facebook API (given the previous temporary token has expired) -- without bothering the user to grant permission again.
So, in short, for short term use, follow client-side authentication flow and for long term use follow server-side authentication (given you have a backend server of your own).