Some Concerns on User Account Data Pulling

**vw729** · Nov 9th, 2010, 01:15 PM

This new project could be very helpful for our clients if it could do a good job on user account data pulling and content sharing.

I would like to discuss the user account data pulling first and leave content sharing for another time.

In my mind, a new user account of our application can be created in the following fashion. After a new user sign in with his/her exist social media login data, the account data will be pulled into our system and this user needs to fill in any missing data requested by our system, but not by the social media site. I am thinking of a few issues in the regards. With this approach whether we will trade security for convenience or not? While security is not a big concern in any social media sittings, it is a big deal for our system. FB uses user's email address as the login ID and Twitter use either email address and user name as user ID. A user account with an email address as the user ID is much easier to get hacked.

I haven't studied the code yet. I don't know how to handle the uniqueness of user name when we pull user account data from various social media.

**habuma** · Nov 9th, 2010, 02:47 PM

Originally Posted by vw729

FB uses user's email address as the login ID and Twitter use either email address and user name as user ID. A user account with an email address as the user ID is much easier to get hacked.

Certainly different applications will have different security requirements and there's not a one-size-fits-all answer for deciding how to represent a user ID. This actually has little to do with social integration and more to do with the design decisions made when considering your application's security and how user IDs will be represented in your application.

As you pointed out, a user account with an email address as its ID is a bit more hackable. If that's a concern for you, then don't do that. Decide on credentials that are fitting to your application's security requirements.

Now, once those decisions have been made, you may choose the convenience of letting your user's create their account based on the information in their profile on some social network. In that case, Spring Social can help. But again, that's an optional convenience and even if you choose to use it, you may choose to use certain information in their profile and disregard other bits of information.

In any case, synchronizing accounts with social profiles is really only a single use-case in the bigger Spring Social story. The more exciting stories involve enhancing your user's experience with tweets from Twitter, knowing their friends on Facebook, enabling them to send tweets based on events in your application, alerting them to real-world events that coincide with their TripIt itineraries, etc, etc.

**Keith Donald** · Nov 9th, 2010, 03:20 PM

As Craig mentions, what's appropriate for your application depends on your security requirements.

Greenhouse supports sign-in by email address OR username, and the Account username field itself is optional. I could imagine a mode in which sign-in by email was disabled and the username field was required then. Would you find it useful if Spring Social provided a sign-up and sign-in module that could be customized in that manner?

It's definitely a useful feature to support automatically populating your local Account profile from a linked social profile. Greenhouse supports this to some extent already. Specifically, when you "Sign in Using Facebook", if the Facebook access token obtained from your local browser cookie is not associated with an existing Greenhouse Account, you'll be redirected to a signup page and the signup form will be pre-filled from your Facebook profile information. In this case, yes, your email address will be populated because we got it from your Facebook account -- but it won't necessarily be usable as a sign-in credential unless your application allows for that. In Greenhouse, a specific FacebookSigninController handles this case; if we supported "Sign in Using Twitter", for example, we could have a TwitterSigninController that maps Twitter profile data onto the signup form as well.

Do let us know what else you're looking for in this area once you take a look at the code.

Keith

**vw729** · Nov 9th, 2010, 05:23 PM

Originally Posted by habuma

...

Now, once those decisions have been made, you may choose the convenience of letting your user's create their account based on the information in their profile on some social network. In that case, Spring Social can help. But again, that's an optional convenience and even if you choose to use it, you may choose to use certain information in their profile and disregard other bits of information.

That is the approach in my mind. Our application requests a username as user ID for a user account. It has a Spring Security mplemention already. I believe the SS suggests to have a username as a user ID. If a user data is pulled from FB, we may just use the email account ID of this user's email address as the username. On the other hand, our application currently doesn't ask for user's gender nor DOB. We don't mind to have those data though.

Originally Posted by habuma

In any case, synchronizing accounts with social profiles is really only a single use-case in the bigger Spring Social story. The more exciting stories involve enhancing your user's experience with tweets from Twitter, knowing their friends on Facebook, enabling them to send tweets based on events in your application, alerting them to real-world events that coincide with their TripIt itineraries, etc, etc.

For content sharing, our application currently already uses the ShareThis widget on every possible pages. I expect this project will bring the social media content sharing to a much high level than what ShareThis does.

**vw729** · Nov 9th, 2010, 05:32 PM