I'm trying to create a RESTful API for a game.
The game will support both anonymous users (users that just want to play now) and users that are willing to register.
What I'm trying to achieve is that while an unregistered user is still using the same computer, data associated with them will be persisted. I'm having troubles meshing that well with also having proper user support for those who choose to register.
GET users/create Users.create
will create a new "anonymous" user which will return back the user (and a unique token it can be identified by)
POST users/register Users.register
will take an optional token (if the user was previously anonymous), an email and a password. It will create a new registered user (with the same token, if one was provided - or a new one).
POST auth/login Auth.login
will take an email address and a password, returning the user if successful
POST auth/authenticate will take a unique token, returning 200/500 based on whether or not the token exists in the database.
Basically, every call to the server will require one of these unique tokens. I'll be able to use that to track which user it's associated with.
My real confusion comes in when trying to implement some sort of "remember me" function for registered users. If a registered user has one of these unique tokens available, can I use that as the remember me token? It seems like this is a poor choice, security-wise and that could cause for a lot of auth/authenticate failures. Since new tokens have to be created each time a user logs in at a new computer.
Am I completely missing something? This whole process seems to have security disaster written all over it. Is there a good recipe out there for this sort of behaviour?
Cheers,
Ian
The token (as a unique identifier in a cookie stored in the browser) is the only way (that I'm aware of) you can use to identify the user uniquely taking in account that Play is stateless.
The key would be not to send the token as a parameter on the request, but to retrieve it from the cookie (play session) directly on each request.
About safety, it should be relatively safe. The cookies in Play are secured cryptographycally, which means they can't be altered or forged. If you add SSL on top, they shouldn't be sniffed, so no one should be able to "fake" another user. To further enhance this use an UUID (harder to generate a valid token) and it should work.
In fact when you think about it the only way to have a "session" in Play is to store the user id (or some identifier) in the cookie of the application, which is basically what you want to do.
Oh, and as noted by Brian Kelly, don't use GET to create a user