SecureSocial-Neo4JUserService
Neo4J user service plugin for secure social (play framework/scala)
Project on GitHub: SecureSocial-Neo4JUserServiceBackground
Building reactive web applications with play framework and scala often starts with a social login system. One great way to get started here is to use Secure Social. They provide a simple way to get up and running with a large number of providers. Once you are running you will need to store your account information and more the likely the relationships between your social users "friends". This is where Neo4J really shines.
Requirements
- Play Framework play
- Secure Social plugin for play Secure Social
Setup
Once you have secure social up and running all you need to do is add this scala file to your play project. I created a app/servicies directory to place the file. Next you simply need to add a line to your play.plugins
play.plugins
9998:service.Neo4JUserService
Neo4J Structure
Users will now be added to your neo4J with the following structure
(u:User)-[:HAS_ACCOUNT]->(p:Provider)
You can also use the utility methods outlined below to make users friends
(u1:User)-[:FRIEND]->(u2:User)
Helper methods
Here are number of usefull methods for helping you to work with secure social and Neo4J
object Neo4JUserService{
def socialUserFromMap( umap: Map[String, String]): Identity = {
...
}
def makeUsersFriends( uuid1: String, uuid2: String ) = future{
...
}
def socialUserFromToken(provider: String, token: String) = future{
...
}
def uuidFromProviderInfo( provider: String, id: String, name: String = "" ) = future {
...
}
private def createUserAndProvider(name: String, id: String, fullname: String) = {
...
}
}
Things to consider.
You will still need a way for users to "link" multiple providers on your back-end. Currently if a user signs in using another provider, they will get another user and provider record in Neo4J. You could try to combat this at the login level by looking for emails that are same as other providers (you would want to verify the email before linking for security reasons)
Another way would be a settings section on your site when a user is loged in, that would allow them to "link" their other accounts. In this manor you would want to create to continue to build a structure like the following
/[:HAS_ACCOUNT]->(p0:Provider)
(u:User)-[:HAS_ACCOUNT]->(p1:Provider)
\[:HAS_ACCOUNT]->(p2:Provider)
The idea I wanted to work on included the use of a TI Sensor tag. This is similar to apples iBeacon technology and uses BlueTooth 4.0 Low Energy. The low energy means that the devices work for low range, but also that some will operate for over 2 years on a coin battery. We intended to use a number of TI Sensor tags and an android device to get accurate indoor positional data. Once we had an accurate position and an orientation for the device we planned on allowing you to interrogate your environment. This environment interrogation would take form as a kind of Augmented Reality looking through the devices camera. I had imagined the terminators red view of the world with constant printouts of scanned objects ;)
Now that I have openfire up and running... the next thing I want to do is to customize it to my needs. The normal way to extend openfire is by way of plugin. This allows you to enjoy future upgrades of openfire while not blowing away your source code additions. Admittedly it took a little more digging that I would have liked to find the right getting started guide.
