I have an existing website in MVC4.
Now I am looking forward to upgrade it to MVC5.
I wanna use External Authentication, however, what I want is that when use select any of the External Login option (Except Twitter, I am not going to use it), all I want is to get his/her Name and email address.
I don't wanna store anything in the database with the username or other details associated.
I just need to grab the Name and email address and if it matches with existing email, user will be logged in, otherwise, new account will be created.
It will be great if anyone can help me with this with small tutorial, to read Name, email and other extra details from the user, instead of adding it to the database.
Related
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.
My question is almost the same as this one
only difference is that users has an option to register (provides his username and password).Users should only have one account registered, if the user has the same email I merged those accounts. and my application has another method for logging in which is via Facebook.
What I basically do is
When The User visits the for site for the first time, he or she then
gets created a User Account where the it only has Username ,password
and mail address after that third-party identity record is created
and then paired with the local account.however the Users table will
have an empty Username and password, but the email will be filled
with the users email that we have retrieved from the third party
service provider
And the Second Scenario
Users attempts Register to the site. check if email exist if the
email exist but it is registered using a third party account, Use
the user populated form and insert it to the user account paired
with the third party account, in short if the users email exist in the database I
will just merged the locally created account and the third party
account.
Now my question is my approach secure and credible? if not what is the best way to merge accounts and at the same time if the user registers with the same email(the one from the third party account) and he has a third party account, those account would be merge?
The way I look at this, there is only one account. One email, one account period. There might be various attributes associated with that account, like for e.g. linked to a set of OAuth credentials etc. But fundamentally there is only one account. If your user has registered once using a social account and then try to register again on your site, send them over to the social site which they used to register the first time and ask them to login there. Then log them into your site automatically. If the user has an account with your site and then tries to register again with a social account, tell them that you already have an account on the site and ask them to login. IMHO, keeping separate accounts and trying to merge them is a messy idea.
I would provide two sets of behavior, one when logged in and one when logged out.
When logged in, you provide the ability to link to new third-party accounts. For example, you sign up with email address and password, then log in, then you can link your Facebook account. To link your Facebook account you authorize with Facebook and then store the Facebook information in that user account record.
When logged out, you must log in with existing credentials. If, when logged out, you try to create an account with an existing email address, you either prevent the log in, saying "an account with that email address already exists", or you immediately challenge the user to log in to merge the account (in which case it works like the logged in case when linking an external account, only with the order of authentication operations reversed).
In case it's not clear from the above, I recommend having a single user account and a way to record linkages between that account and external accounts. You can do this in NoSQL buy just adding fields to the user document or you can do this relationally by having a table representing external accounts with a foreign key linking them to the user ID.
Beware not to use oAuth 2.0 !
The lead author himself resigned as it's not as safe as the 1.0 version.
You should prefer oAuth 1.0 or OpenID.
You can also have a look at Persona from Mozilla
I have a project where I am using Selenium to test the Facebook auth. I created a Facebook app, created a test user inside this app and created some tests using Facebook login. Until now, it was working. But during the last two weeks something changed in Facebook and my tests are failing. It is due to interface changes in permissions dialog (I am targeting the button by his id). The second problem is that I don't get the email address from Facebook test user but a proxy email which is longer than 75 characters (my db field length is hardcoded in framework I am using).
If I log in as a regular user, it is working correctly and I get this permission box:
But when I log in as the test user I created (via 'switch to' in app's developer roles), I get this box:
I tested it ~2 weeks ago and this was yet working. Today it is changed. So my questions:
How to get back the old permissions box for test users?
How can I get the real email address and not the proxy?
Thanks!
I experienced the same problem with the Auth Dialog. I tried it with some old and new apps with various settings including March/Apr. 2013 Breaking Changes enabled/disabled, but it didn't help.
However, I guess I can help you with the email problem. When you login as a test user and go to account settings page, you will see the test user's primary email addres. By default this should be a really long one like the image I attached.
Facebook Platform returns this primary email address. If you pass the Auth Dialog with your test user account and see the privacy setting page, you will find the default primary email address is shared with the app. You have to provide a new email address for the test user and set the new one as primary email address via account setting page.
Why is the Login Dialog different with a test user?
With your test user, you can see the future of login dialogs. In fact, this isn't "not working" but this is an update which was unveiled on December 2012. Let me quote:
Our Login dialogs have undergone a redesign to make it easier to
understand permissions that apps request. We've simplified
presentation and have also updated our language for greater clarity.
“Basic info” has been renamed to “public profile and friend list,” to
reflect what what is being shared. Apps accessing your public profile
get your name, profile picture, age range, gender, language, country
and other public information.
Source: Providing People Greater Clarity and Control, developers.facebook.com/blog
The reason why you don't meet this update with a regular user, is that Facebook doesn't use to update everyone at the same time. They partially launch updates depending on the country, the type of account or some other parameters I ignore.
Example of a partial update (unified_message FQL table) dedicated to developer accounts:
We are providing early access to this API for registered developer
accounts only until the new messaging system is broadly available. You
should use the message table for production applications at the
current time.
In our case, we now know that test users can access to the update, but it is also said:
We have already launched many of these improvements as part of our
iOS6 integration and are now rolling them out more broadly.
About proxy emails
In fact, proxy emails are a way for any users to keep their real email anonymous. You have to consider proxy emails.
When joining an app, the user can choose between a real email and a proxy email:
Other thing you need to expect are users who didn't validate their account when connecting to your app, a case which is possible as described here and here.
Then, why do test users give back a proxy email? Because test users (being bots and having fake emails) didn't validate their emails.
You see that in at least 3 cases (and finally, test users are a good example), you need to handle these proxy emails. They are incidentally or accidentally met by developers and they can't be neglected. For your case, you can still try to disallow tests users who have a proxy email from accessing your app. But you should accept them and shouldn't force them to share their original e-mail addresses. A better solution is that you validate the test users emails:
Connect to the test user account that gives a proxy email
Add an email address (password needed here),
Go to the email mailbox and click on the validation link,
Set the new email address as primary,
The test user should now give his original email and not a proxy anymore!
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.
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.