I have created a public facing website which allows you to login using a username/password, or with Twitter, or with Facebook.
When logging in with Twitter for the first time (for example), a user is created in my database with a nickname matching the Twitter screen name. I want this nickname to always be unique.
The problem is that in some cases a user with that nickname already exists, so the user can't be added. I am unsure as to the accepted approach for this problem, the only solution I can see so far is to ask the user to override their nickname, but this doesn't seem too elegant.
The reason the nickname needs to be unique is not a code issue, but an interface issue, for example there are forums and I want each user to be uniquely identified by their nickname.
Are there any other methods anyone can suggest for dealing with this problem?
Edit: At the request of some of the replies I will clarify an example:
Lets say I have a user named Joe Bloggs who is a member on my website. He is not a member of Twitter or Facebook. His nickname on my site is JoeBloggs.
Then, another Joe Bloggs comes along, and wants to sign in with his Twitter account. His Twitter name is JoeBloggs, so when he signs in with Twitter, my system attempts to automatically set his nickname to JoeBloggs. However, this nickname already exists. What is the normal or best practice in the cases where nicknames like this overlap? The only thing I can think of is to prompt the user to specify a different and unique nickname (just for display on my site).
The reason I ask is that this must be a common issue for sites which let you login via Facebook, Twitter, Yahoo - there must be an overlap in the names which are returned from said websites, so I wondered what the normal process is.
Could you use the Twitter API to confirm they really are the Twitter ID they say they are, and if no Twitter account, allow them other means to authenticate (Google+, Facebook, LinkedIn, old school username and password)? Allowing users to login with a Twitter ID that they don't own seems like asking for a world of hurt.
Maybe you could try and change the database itself - get a field like 'nickOrigin', allow there values like '[yourSite]', 'twitter', etc., and only allow new entries if no entry with the same nick AND nickOrigin exists. Execute a query to modify existing users to have a nickOrigin of [yourSite], and things should be backwards compatable, or at least I imagine them that way :)
Related
I found that vine://user/907031926412546048 is working.
is there any way to open by username? vine://user/canaksoy
or any api call to find username by userid?
I would shy away from hard coding this. Usernames can change instantly and by hard coding it in, you literally would have to push an app update just to correlate to that new username. I think by using a user ID number its guaranteed and leaves no room for error. But if you really don't want to do that here is an alternative:
This is untested on my behalf, but I do know they have custom urls, you might be able to play with this:
https://support.twitter.com/articles/20170806-vine-profile-urls
A profile URL is a unique Vine profile address accessible from the web. Once you select an available URL you will be able to access your profile by visiting vine.co/[yourURL]. Selecting a custom URL allows you to share your profile easily and makes it easier for others to find and watch the videos you’ve created.
EDIT based on the discussion below :
This is why it's important to use unique ID :
A quick search for everyone with the username of Drew Carey:
This is why they don't have usernames in my opinion. Because they aren't unique. Even vine utilizes the unique ID when you invite someone to see your vine or profile via text or email. Additionally, when you sign up through twitter it shows your real name. There is too much room for error. I would simply ask the users to enter their custom url if they have one or unique ID until this feature is available publicly.
I am developing a MVC project where I am trying to get the user id or user name from the facebook by using the email id provided by the user,
actually i want to fetch the photo of the user, which can be done using
graph.facebook.com/user_id|user_name/picture
where as i have only have the user email id.
with a little surfing on net i found that user name or user id can be fetched by using
graph.facebook.com/search?q=emailAddress&type=user&access_token=ACCESSTOKEN
but i was not able to get the access_token.
Also referred
developer facebook page
and also this
Any help or direction to work will help indeed.
Basically i understand that i need a access token to get the details.
So how do i do this in my MVC application
As you can read in the Search API docs, you can only search for Users by name, but not by E-Mail. It may have been possible in the past, but it is definitely not possible anymore.
Also, for searching by name, you need to use a User Access Token. You only get one by authorizing a User: https://developers.facebook.com/docs/facebook-login
I'm using Devise with my Rails app and I'm looking at using the Omniauth-Facbook gem. My app has views that show the users's by user name. What I haven't been able to figure out is how I can prompt a user for a user name when doing this.
I know that I can request this from Facebook, if the user has created a FB user name. Many people have not specified a user name for their FB account, so this does not seem like the best approach. I've read other answers which indicate that perhaps the email should be used instead, which works if the user name is solely for logging on, but this is obviously not a good idea if the user name is going to be shown on user views.
If anyone could provide guidance on how to best prompt or get a user name while registering someone through Omniauth-Facebook, that would be very appreciated. Thank you!
when you sign up for facebook, then check whether they have username in the facebook, if no,then just redirect to your path to update the username?
I am adding Twitter and Facebook login to a MVC 3 test application using TweetSharp and Facebook C# SDK.
Currently when a user signs in using Twitter I create a user account for that user in a user table and store the id, token, and token secret in a separate table with a foreign key to the user table. Since the id, token and token secret do not expire I can quickly locate the right user account when the user logs in next time using Twitter.
What if the very same user logs in using Facebook next time? Since Twitter does not provide email in their API and I therefore have no common piece of information to tie a user account to either Twitter or Facebook I assume I have to create a new user account for a Facebook login? Does anyone have any experience with this? Are there any ways to solve this?
I identify each user internally with a unique key. I check cookies for the user key when any user hits the site. If there's no cookie I create a new key. add it to the user database and set a new cookie. Once a user completes registration the first time by logging in with any of Facebook, Twitter or .Net membership , that key is forever married to that user.
So when an existing Twitter user logs in for the first time with Facebook, we know who they are because their user key exists. It is basically the same solution as macou suggested. Macou's has the plus of working on a new machine or if cookies are cleared, the cookie solution has the plus of not requiring additional user input.
Not really a solution, more of a work around. I was faced with the same problem and ended up forcing the user to complete thier account profile by asking for their email address before allowing them to proceed any further. This meant that if the email address coming back with the Facebook auth matched the email address created with the twitter signin then I didn't need to create another account.
The bigger difficulty was coming the other way, if the account was created by the facebook auth first. It meant an untidy marry up of accounts.
To be honest the information we got from allowing users to sign in with twitter was not worth the effort and in the end finished up only allowing Facebook auths. I'm not sure how important twitter is to your solution.
Not the perfect answer I know, but I thought I would share my experience.
You can't use just a cookie because I can login as facebook then my wife login as twitter using the same browser, you shouldn't link the two accounts in this case.
I think you need to do more than that:
Use a cookie then
Use name/first name/login name/... to see if they match.
Example:
Cookie id: 18459439731114330636, find user with id = 18459439731114330636. Found, go to 2, not found, go to 3.
Is username/first name/last name/... matches the current user? if yes, link accounts. if not, go to 3.
Create a new user.
I have a website with it's own login/registration mechanism (PHP, session, user and user_profile DB tables with username and password, etc). Let's call this the ABC account.
I just finished integrating Twitter's sign-on using Oauth, available as a "sign-on using twitter" button above my normal login form.
So now I have this scenario:
A user logs on via Twitter. Because Twitter, unlike Facebook, does not proivde access to a user's email address, I don't know if this person who logged in via Twitter is an existing user (in my user table) or not. So I create a new account for them (let's call this the "Twitter" account) and prompt them to merge with an existing "ABC" account by entering their "ABC" credentials. If they do so and everything matches, I store their twitter username, id and token in the DB record for their ABC account. Next time they login via Twitter I know who they are in terms of the ABC account (ie, the accounts are "merged") and all is good!
Except, I'd like to have the ability to have my site send tweets on their behalf, which basically means I need an authorized Twitter connection, which I only have if they logon via the Twitter button, not through the ABC account. The reason is with the latter I have their token_secret, received from the Twitter API callback after signing, but with the former I don't. My first thought of course was to save the token_secret in my DB (with the ABC account record) to remove this restriction, however it seems like this is the equivalent of a password and storing it could be secruity hole?
To boil this down to a question: is it "standard" practice to store the oauth token secret in the DB to achieve what I'm trying to do (which itself seems like a pretty standard function for a modern site)? . If not, what's an alternative implementation?
Update: looking at: Best practices - store Twitter credentials or not? it seems this is definitely not a 'best practice'. But it seems like what I'm trying to accomplish is...not sure how to implement? Maybe some kind of cookie-based solution??
Peter
ps -- BTW, if anyone has a better way to do the account "merge" I described I'd be open hearing about that as well. I did some google searching but really couldn't find anything too useful, although this problem must have been solved many times I imagine??? My understanding is that in the Facebook case the email can be used to "uniqely" identify a user (ie, match them to an ABC account), and do the merge without prompting (although I'm not even sure this is totally secure?).
Storing the tokens that Twitter gives you during the OAuth process is -exactly- how you should be doing it. Shove them in the DB.