We're implementing a Facebook-connect mechanism to allow users to sign up into our system. We receive their email address and other details at sign up.
I'm not sure how to handle the scenario when the FB-user changes his email address at Facebook itself and subsequently logs into our system. I dont think there is a mechanism for us to detect that (or for facebook to notify us).
How do I resolve this situation?
Create a table in your database that holds the FB userId, and the email address and use the FB id as a foreign key anywhere where you need to refer to that user. Then, at some regular event like when the user logs in, places an order, or updates their profile, etc., get the email from the facebook profile and update the table.
Related
Background:
I am making an app which will be a public app and will put it on Shopify App Store.
I have completed with the OAuth process and I get access_token and scope in return which is good. I can now use this token and send API requests with X-Shopify-Access-Token in the header.
But, for my database design, I need the user details as well, like user ID or email ID for example. However, I read the docs(scroll up a bit) and it suggested in the caution section that email address is not reliable to identify the user(merchant). I also gave a read on access modes which is online and offline, and in my case, I would need an offline access token.
Question:
How would I get a User ID from Shopify during app install so that I could uniquely identify each merchant?
One of the reasons I would want to have this is because a single merchant could have(or see) multiple stores linked with my app and I wish to show them details for each store under a single user account.
When a merchant installs your App, during the oAuth flow, you are presented with the shop name. That is unique, and will always be present for incoming calls to your App from Shopify.
You do not mess around with email, or user ID's. You simply persist the access token you got in your data store, with the shop name.
If you wanted to group by a merchant name, you know each Shop object provides the shop owner details. So you can always dig those out and store them along with the shop name, allowing you to show one merchant, many stores.
I have created a nice little login script for my website that lets users login with Facebook or Google at the moment.
What I am trying to do is set some checks to make sure that duplicates do not appear in the database.
Here are some scenarios I have covered :
Login with Google/Facebook account and I have already registered this account, This will log the user straight in as they have already linked this account.
User has already registered with Google account, yet clicks Facebook because they cannot remember which account they used. This will alert the user that the email address returned from Facebook has already been registered with a Google account. This will enable them to click on Facebook to Login ??? NOT SURE ON THIS LOGIC AT THE MOMENT ???
User clicks on Google/Facebook to login, yet the email address returned is a user that went through the manual registration. This will alert the user that the social account they are trying to login with will require a password.
What I am thinking of doing is allowing users to LINK ACCOUNT so that the alerting process does not happen because I can link my facebook account to my google account through my website, and vice versa etc etc.
What I am asking :
Are there any other checks I may be missing? Is this logic sound? Is there anything I am doing which makes you question the login process??
Basically asking logic advice on this one.
Well congratulations! You're almost on the right track. Let's breakdown your situation here.
Ideal Situation
1. Registered on your site
2. Log in with Google
3. Log in with Facebook
Now, let's take the common denominator here, I mean the primary key. I am guessing in your case it should be the email address.
Actual Process Flow
1. User registers. You save the email address
Or,
2. User registers with Google/Facebook and you save the email address.
Login Procedure
1. You receive the email address either from direct login/facebook/google.
2. You match it against your table
3. On positive match, you link this social login to an existing account
If,
4. It is not a positive match then you accept whatever data you receive and then forward
and then pass on to the registration page.
Hope this helps! Let me know if you want to know anything else.
Cheers!
Let's imagine that we have ecommerce website that suggests 3 way for user registration:
regular email
via facebook
via twitter
Now let's imagine that we have user signed via facebook/twitter account and we need send him notification about his order (order complete or s/t like that). How can we do this? It is absolutely clear for regular email users - we should just email them notification, but what about Facebook/Twitter users?
Thank you!
With Facebook when they authenticate with your application, you can request email permissions to be able to access the email address they have nominated to use with their facebook account. At the point of registeration you could then store this address in your database and all order flow could follow the existing email path.
You could probably re-use this methodology for twitter too.
I can understand the need to differentiate on registration processes however I think you want to streamline post order notification as much as possible for consistency across users.
I've integrated social logins (Facebook, Twitter, etc.) with a Rails app using Devise and OAuth. The requests and callbacks all work great and users are able to authenticate the app and login efficiently.
My problem is this:
With Devise, my site has the user's email address as the username. So, whenever a user logs in through a social site for the first time, a 'connection' record is stored for their account to show which social sites they've logged in with. If they don't already have an account on my site, one is created with the email address from the callback array. The connection is then stored along with the returned tokens and secrets for later use (FB posts, tweets, etc.).
Unfortunately, Twitter doesn't provide the email address. To circumvent this, I'm asking first-time users that login with Twitter to simply provide an email address so an account can be created. However, I can't figure out what to do if they already have an account on my site. I can't check if they already do since I'm not given an email address to match up. This could ultimately cause a user to have multiple accounts.
So, I'm a bit at a loss, and if anyone has any suggestions, it would be extremely helpful.
Thanks! :)
You'll need to store some oauth provider info like {provider, twitter identifier} too to your database and then check twitter oauths based on that instead of the email ID.
The simplest thing to do would be to add a slightly different flow for if the login was via twitter. Ask a first time Twitter login user for the email ID. In your users table, add a column called tw_id and add the users twitter identifier. Next time, if the login is via Twitter, you check the tw_id instead of the provider email and proceed with the normal app flow.
The problem I see with single login services, is that if you login once using Facebook, once using Twitter, and once using LinkedIn - you have three different accounts. Everything would be fine, if Twitter was giving an email address. So, how do you fix it?
I have the same problem and I was hoping the clever folks on SO would have an elegant solution. All I can think of doing is :
User logs in with LinkedIn
Check the user table to see if they have an account using their LinkedIn id
If not, ask them for their email address before logging them in
When we have the email address, check to see if they already have an account using their email address
If they do, add their LinkedIn ID to this record and log them in
If they don't, create a new record and log them in
This means that each user record needs fields for every possible account, or more correctly use a link table connected to their local user id with a record for each account they log in with.
It also defeats the benefit of a simple OpenId login because the user has to register their email the first time they login with a new OpenId account.
Like I said, elegant it ain't, but it is the best I can think of.