How do I get old UserID as of Graph API v2.0? - php

In numerous applications I've written, every time I want to give user an opportunity to log in through Facebook, I get their user id after logging in and pair it with my app's user account. However, after an introducion of v2.0, I'm not pretty sure how should I pair them. If I upgrade now without making any changes but changing API endpoints, I end up with duplicate accounts due to inconsistency between User IDs (I'll be searching for a new (APP scoped) used id in database with old IDs). How should I upgrade without losing every user consistency?
To demonstrate how do I retreive their accounts, I'll join a bit of PHP here
<?php
$user = $db->fetchQuery("SELECT * FROM users WHERE fb_id = ".$facebookSDK->getUser());

Consistency should be fine here, within a single app.
If a user has already authenticated with an app prior to 4/30/2014, the id you receive will not change. For new users authenticating on or after 4/30/2014, you'll get an 'app-scoped' id which has the same format but is not the canonical 'fbid'.
For apps owned by the same developer, the Business Manager can provide mappings for users across app-scoped ids in different apps.
https://business.facebook.com/

There is a dirty hack to retrieve original facebook id
http://graph.facebook.com/app-scoped-id this returns facebook public informaton along with username
Then you make another graph api call with username
http://graph.facebook.com/username
This will returns the original facebook id and other public information, instead of app-scoped-id

Related

Storing data related to facebook user in database

What I'm trying to do is implement a "log in with Facebook button" on my site. I think I have understood most of the Facebook JS API, yet I am not certain of how I securely can tie information in my own databases up against a Facebook user. My current theory is:
1. Register Facebook's UID for the user in database for further reference.
2. Tie all further information from the user (the infromation inputted by the user in the application) up to the user ID after verifying the Facebook access token (in the backend), to prevent user from adding/removing information on behalf of another user.
3. When the user makes a query for information, you verify the access token issued by the JS API in your backend up against Facebook's APIs before returning any information related to the user, to prevent the user from spoofing his own ID
Side note: Not sure if Stack Overflow is the correct place to post this question.I know that there is an enormous number of sub sections on Stack Exchange. If this isn't the place then let me know :)
I implemented a login with Facebook module in my recent node project. When the user logs into Facebook successfully, it usually returns a unique Facebook ID (along with a lot of other data). You could then create a relation table in your database that relates the unique Facebook ID with a special user ID for your site.
If you have facebook info you are going to need frequently like profile image... I would grab the url every time and store it in a session variable when the user logs in simply because it can change.

App-scoped IDs in Facebook group members request

I am the administrator of a Facebook group, and I created a site where I use FB login to identify my users; users of the site are supposed to be also members of my FB group.
Before the introduction of version 2.0 of Facebook API I used to store the ID of people logging in through my app in a mySql DB; since API 2.0 app-scoped ID have been created (https://developers.facebook.com/docs/apps/upgrading#), and I've understood how they work.
I've noticed that users who have logged in after the introduction of 2.0 API have the (longer) app-scoped ID, while old ones are keeping the same old ID (as I expected).
Now my question: I'm writing a small code to check if members of FB group I administrate are users of my site too (i.e. if their IDs have already been stored in my site's database), but I've found that a lot of IDs obtained through this code:
$members = $facebook->api('/'.$userGroupId.'/members','GET');
foreach($members['data'] as $data) {
echo $data["id"]."<br>"; }
are different from the ones I've stored in my DB.
The same user seems to be identified with 2 different IDs, one for login and another one for the group.
So, what's going on?
I suppose is something related to app-scoped IDs, but so far I haven't found a clear explaination on how FB group members IDs work...
Hope that someone could help me to better understand the logic behind user IDs on Facebook groups.

How should I handle the user data after the user login through Facebook

Currently I am using the traditional way to implement member system e.g. A user table and other related table (e.g. user_product) has a foreign key to link to that user
The problem is , how can I work with the member login through facebook?
e.g.
Should I used the retrieve info from facebook to create a new account
for them automatically in my user table?
Should I create a new table e.g. facebook user , then insert in it?
Should I just ignore the login info, without adding it to my database?
The problem I encounter is there is an user_id and people login from facebook will not have it. Therefore, when they use the function e.g. purchase , I can not insert the record. However, if I add them to my user table, there is some info. missing e.g. password, phone..... So what is the common parctise of handling login through facebook? Thanks
There are a few different ways this is handled in practice. Some services require a user to still fill in information, even after the user clicked "Login through Facebook". Unless there is information that you absolutely need, I would advise against this approach.
You could take a polymorphic approach to users and have a regular users table and a Facebook users table. There are other ways to approach inheritance in SQL databases too, but this can get complicated.
A third approach would be to have Facebook id and auth tokens as nullable columns on your users table. This would also require you to either make the password column nullable, or set it to something long and random. This way, Facebook associated accounts function identically to other accounts, with the exception of of the way they sign in. Since you have their email, it should still be possible for Facebook users to make use of a "Reset password" option to get a password.
Edit:
You'll need to create columns for the things you need in order to maintain a Facebook record for a user. Facebook id, oauth token, and oauth secret are among these. When a user clicks sign in with facebook, upon receiving a response from Facebook, you should run a check to see if there is a user with the given facebook id. If one exists, sign the user in. Otherwise, create one.
Even easier would be to look at an OmniAuth solution. OPAuth is one such solution. Introducing something like this may require you to rework some existing code though.

Reusing OAuth Access Tokens

On my site, I intend to offer users the ability to authenticate via OAuth. I don’t want to ask them to first register with me and then connect an external account; I want to offer single sign on.
I believe we’re supposed to reuse Access Tokens; certainly within sessions and even between them.
Google goes so far as to say they’ll limit the number of access tokens to 10 per user per application. (Apparently Google still supports OAuth1, but recommends Auth2 now) 10 is a pretty small number.
Using cookies (like this) seems like a good plan for identifying a user between sessions, but I’m having trouble with the scenario where a user has deleted cookies or connects from a new machine.
How do I know who the user is before I’ve requested another Access Token for them? Request tokens do not contain the userid, right?
Thanks
You will have to maintain your own user accounts anyway, no matter which protocol and which provider you choose. A token (or a URL in the case of OpenID) that you get from a provider is unique for a given user and you are supposed to associate it with your internal user account and recognize user by it.
If you don't want to provide any registration UI it's okay: just get the token, retrieve all the user info you need from the provider and store all this somewhere in your database. You will also have to issue and recognize your own cookie for your users, or else they'll be forced to go through provider auth every time they visit your site.

Creating a leaderboard using Facebook APIs and the PHP SDK

I'm a new Facebook developer. I'm creating a game and want to include a leader board.
I'd like to build a fairly detailed leader board including the following information:
1) Name
2) Pic_Square or profile_pic
3) A general location (UK, USA or LONDON, NY)
4) Score
I'm aware of how to get a current users basic information from the either the old REST API or the Graph API. However from what I understand of the Facebook rules I can't store the information I want to use from the API.
This leads me to the conclusion I should be polling the Facebook API using the information I can store (FB user ID's). When querying the API for specific user ID's (the ones for the test users I have generated) API methods (user.getInfo and fql.query) return either just the ID of the user or the fields I have requested with null values.
When querying my own ID I can access all the data.
Are there any methods to obtain publicly available data via the any of the APIs?
Thanks for your help!
Ben
Why do you think that you can't store this info? On the user table page it even says:
You can cache this data and subscribe to real time updates on any of its fields which are also fields in the corresponding Graph API version.
If you request offline_access permission you would be able to get user information even when a user is not currently logged in to your app.
You should be able to get any user public info without permissions or access token by going to:
https://graph.facebook.com/<USER_ID>
To display avatar you can use this code:
<img src="https://graph.facebook.com/<USER_ID>/picture"/>
I don't think you would be able to get location without requesting extra permissions.

Categories