As far as I know, on the new Facebook API, there is no way to get the Facebook username. Also, if the user registered to Facebook, his or her account might lack an email address if he or she logged in with a phone number.
However, I am working on a project, where, upon login with Facebook, if the user does not have a user, then the Facebook login is interpreted as a registration. Since, according to my best knowledge, there is no way to get the Facebook username using the API, I am using the email field to generate a username, taking into account only letters.
However, in some cases, the username generated this way is duplicated, or the Facebook account does not have an email address. The best solution I can think about is to redirect the user to a form where he or she can enter the email and/or the username, but that would not help the user-experience.
Is there a way to gather these data without making the user enter them? Or something close to it?
First of all, you should always present the data you want to store to the user BEFORE you store it, and let him change it.
That being said, the (App Scoped) ID is the only thing that is really unique, you can either use the email directly (if the user is already registered, just add the Facebook ID to your database) and present an input field if there is no email - or generate a username with his first and last name. Present the chosen username to the user and let him change it, or tell him that it already exists.
After all, wouldn´t a user WANT to choose his username?
If you want to make it smooth for the user and don´t want to bug him in anyway, you can just store his Facebook ID. Or just use the email directly as username (including the # sign and the domain), as i wrote above. If that´s not good enough, you need to implement your own routine to auto-generate usernames. There´s no general logic from Facebook to do this.
Related
I'm about to use one of those multi-provider authentication frameworks Opauth or Hybridauth (don't know which is the best but I had a little preference for the second one) so the consequence is that I have to manage multi account.
In fact I already have my own account management (login+password+email) and I had last year facebook users. Now I will have to deal with Twitter account, linkedin account, etc...
So the question is easy : how to manage the username ?
For instance, John create a account on my site. So "John" login/username is taken. But if another John from Facebook then another one from Twitter arrive, what i'm supposed to do ?
In Stackoverflow (or elsewhere), what is the practice ?
I don't want a John write on the behalf of another John. Today with my own system, I verify that the login (username) is unique. If not I reject the user. But now ?
I thought that I can check the email but... I learnt that email address can't be the key because of Twitter that doesn't give it to you.
Hope I'm clear enough :)
regards
As you say it's not possible to just retrieve the username from different sources and just store it. I don't know how it is done here in stackoverflow but if you try to register the name is optional so probably it is not an unique key. I can't see the way to login with twitter here so I bet that email is a unique key.
I'll try to answer your question but I've only used facebook API so maybe this can't be done with others. I suppose that each API gives you something you can store in your database and use it later to identify your user against their API.
If you allow users to register with facebook (or gmail, twitter...)then you can use the next approaches (I'm sure there are few more):
They always login with facebook (or twitter, gmail...): you store a record for them inside your database with the key provided by the API and other useful info you can collect. As you said each API gives you different things so you have to think in advance what you really need to provide your users with a good experience: is their name needed? age? If you need more data than the provided by the API you should jump to the next approach or prefetch it and make it editable before. Here you don't ask your user for a password so they can only login with facebook not with a login form, if a user tries to authenticate with facebook (or twitter, gmail) again you know which key you have to look for and authenticate your use.
The can create an account and link it with facebook (or whatever): you ask for facebook permission and then prefill a form for them to provide the data that is missing (password, mail if they use twitter...) and then create the record storing the unique key provided by the API as well to proceed exactly as step 1 if they use their facebook accounts to login. If you asked for a password and an email they can use a standard login form as well.
You can use the first approach and ask the user to change the attribute that is in conflict with other user (name in your case) or even ask to fill what is missing depending on which social network they are using to sign in. You can use name+surname as username to reduce the colission possibility if this is what you want to store to identify your user.
Hope this helps
HybridAuth gives you an excellent way to integrate your site with the social media...
http://hybridauth.sourceforge.net/
This should also help...
We are looking to integrate Facebook, Google, Twitter into an existing site.
Unlike most implementations, the user MUST be a customer prior being able to login with Facebook, Google, etc. The current database design is as follows;
userid | username | password | customerno
So the idea is if a user decides to login using Facebook, we need to validate that they are also an existing customer using their customer number which is alphanumeric. Once authenticated, they are no longer required to authenticate using their customer number. If they are not yet a customer, they will first need to create an account with us.
Do I need to design a new table for each provider? If so what should the design look like?
How do I authenticate a user who has logged in using Facebook with their existing customer number?
How do I authenticate a user who has logged in using Facebook with their existing customer number?
That depends on what criteria you have to recognize someone as a customer …
IMHO the best and easiest way to connect Facebook users to existing accounts on some other page is the email address. If you don’t have that, and see no other reliable way to identify someone as a customer with the data that Facebook can provide – then maybe you could just ask the user for their customer id on your site before connecting their Facebook account.
As for your database design – if you read the email address on every connect/login, then you could just look that up to find your user id. Otherwise, you could either add extra fields to your existing user table, where you save someone’s Facebook/Google/... user id. But if you want to use multiple services, maybe it’d be better to put this data into a second table like
userid | foreign_user_id | type
where type would be one of 'facebook', 'google' etc. to identify the login provider that foreign_user_id comes from.
Currently on my website, users login with their login id and password, they are also required to enter their email when they register. Both login_id and email column on the users table have unique index. users table also stores other data associated with the user such as gender,last_name,first_name but these are optional (nullable) fields.
There are two changes I would like to make to the website.
The first one is, users can use their email (in addition to login_id) to login. For new users, when they register, they no longer need to provide a login_id because they will be using their email to login.
The second change is, they can login with facebook. For new users, if they login with facebook for the first time, their facebook uid will be obtained and stored in my database. This means I will have to add a facebook_uid column on the users table.
For existing users, when they login with facebook for the first time, I should first obtain their email address from their facebook profile and then check if there already exists a record using that email in the users table, if yes, their facebook uid will also be stored on the facebook_uid column on that record.
According to facebook, its platform supports two different OAuth 2.0 flows for user login: server-side flow and client-side flow. Which one or both is required for this use case?
Also, what problems can be anticipated when I implement the features like I describe above?
You could take either approach for this, it's entirely up to you. Both methods will give you the data you need, it's a question of how comfortable you are working on the back vs front end. You just need to ask for permission to access to the user's email address.
Problems that could happen: I'm not sure but there may be legal restrictions on storing the user's Facebook ID. Also, what if someone (not me, an evil person!) registers with my email address and you don't validate that they really have access to that address - then when I log in via Facebook, the app will assume we're the same person and the evil hacker now has access to my account. Unlikely scenario but could happen...
I'm working on an app where I'd like to be able to do things with a user's Facebook username. I know that I can get this through the basic user object, but I'm worried about the case where the user doesn't have a FB username when they register with my site/application, but does gets one later. The question is how to test this with FB test users:
A user (a regular user, anyway) has to be verified before they can get a username. Is it possible to verify test users?
If so, is it then possible to give a test user a username?
Is it possible to change that username as part of the testing process (on the chance that my code doesn't work perfectly the first time :)?
What I'm thinking of doing is setting up a realtime subscription on "username", which I've established is possible. If the user above suddenly gets a username, my app gets notified and I can do whatever I do with it. But that implies that a lot of other things are possible, which they may not be. I could retrieve and check the user object on login and keep updating the fields, but I'd prefer to avoid that if possible. Any advice out there?
You cannot claim usernames for test users. You will have to use your own account or test with a real fake account, which Facebook frowns upon.
I've got a decent set of existing users on my website who login via their emailaddress as their username.
I'm setting up Facebook OAuth mechanism to allow new users to sign up more conveniently, but I'm not sure how to handle the scenario when a user who already has an email address registered with our system and now tries to login via Facebook.
Should I consider him the same user?
Should I treat him like a new user?
The situation is more complicated by the fact that I dont validate their email addresses (when they login directly into my system), so i cant assume they are the same user.
How do others resolve this conflict, or do other folks simply treat this user connecting via FB as a new entity?
On your login screen, users can have a choice: you may put
new user: signup using facebook
since this is a totally new user account, then you just need to do your facebook connect + request for email permission, etc.
existing user: login by email
Once they do this, let them login using the old-fashioned way. Then once signed in, prompt them to connect this email address to their facebook account. So the flow is login via email then optional facebook connect.
To do this, I assume you've added a field on your database table for user_accounts, that is facebook_user_id or fb_id or user_id, etc. Then on facebook connect, get the logged-in-email, UPDATE table SET fb_id = xxx WHERE email = xx
I've pondered the same issue. I think we'll go with the verified email (Facebook Connect) getting attached to and logged into the existing account with the same email.
Before we connect and log them in we'll explain that the account exist and ask for their password (they signed up using email and password, so they should know it) to ensure it's the right person.
If you support multiple external authentications (Google OAuth, Facebook etc) then you may not have a password, and in that case it gets slightly trickier.
If you do log them in to the existing account without asking for a password, make sure you clear existing sessions to avoid 'anticipation attacks', where an attacker anticipates that the target signs up, creates an account and keep the session after they've signed up and attached to the attackers existing account.