User registration and logins

Networking & Multiplayer
#1

I’d like to gather some thoughts on how best to do user registrations and logins. I’m thinking about a multiplayer game with both an applet side (the actual gameplay) and a web side (with user stats, game world updates, etc.). Users would have their progress and characters stored server side so they’ll need some kind of username so I can keep track of things.

Since I’m planning on using Google App Engine, the obvious option would be to use google’s sign in (so you can use your google mail account). This is nice because google has done all the heavy lifting with security and password recovery and whatnot, and I just get a unique username to tie everything to.

However I’m not sure if some people would be put off by having to log in with their google details, particularly those who don’t have a google login already. Also, I’m not sure how i’d communicate my login to my applet (passing cookies or sessions via html as applet startup params?) and I’m not sure I’d like to get people to enter their google details into my applet either.

Alternatively I do all the login myself. Which leads to the question - should the username be something that a user picks, or should I just use their email address as their login id? Using their actual email probably means people will use a proper one and not a disposable email address, but I think i’d rather that people had actual usernames.

And if I do things myself, do I attempt to validate the email address (by sending an activation email)?

Thoughts, feedback, etc. much appreciated.

#2

Roll your own.

It’s not hard, make a database with a couple of columns, write a bunch of queries and you’re all set.

be sure to use prepared statements (or whatever googles database uses) to save yourself from the usual injection-attacks

#3

username, email, generated unique ID, validation recommended.
guestuser option naturally also good, for people to test without going through the registration.

#4

I vote for rolling your own login stuff with username, password, and email. Even email could be optional.

I started a project for sending/receiving objects to/from a servlet using my Kryo serialization library:
http://code.google.com/p/legion/
I implemented registration, login, sessions, and a lobby before tiring of it. Someday, when I have an actual project to make use of this stuff, I plan on revisiting it.

#5

I’d say roll your own too (+ a guest pass). No-one’s going to want to give you full access to their google account!
I’m playing with something similar myself ATM & the appengine makes it easy to handle this sort of thing - took me about a day to get it all up and running, including activation emails. There’s an image API for captchas too but I didn’t bother.
If you’re going multiplayer then watch out for lag! It can vary a lot. DB access can also drag at times. You can’t really expect more than 1-2 polls/sec if you’re lucky. :-\

#6

While I think your own login is best, FWIW, using Google to login should be done like http://stackoverflow.com/

#7

I’m trying to figure out the same issue :).

If you roll your own, the email address can be the login username, but the account could have a ‘in-game’ name, so that when in game, you get a nice user chosen name, but no-one ever sees the real account name. I’ve seen this done before.

Endolf

#8

You could still use google IDs behind the scenes. Scrape the signup page for the captcha image, append your game name to the name they choose so they don’t have to hunt for a unique name, make the POST yourself. Users would never need to know they were using a Google account, and wouldn’t be trusting you with their existing account.

#9

Ew. That’s got all the disadvantages of both, with none of the advantages. The whole point of using a user’s existing google id is so that I can piggyback on their authentication and password recovery. Doing it that way i’d have to scrape and reimplement those bit of functionality in horriblly hacky ways.

Also, I’m fairly sure that google would take a dim view of scraping their login and captcha and reposting it. :S

#10

While OpenID is interesting, as a user I found signing up for StackOverflow to be a right pain.

I think the general consensus seems to be rolling my own would be the best and least scary to users. I probably won’t bother with validation emails since disposable emails easily circumvent this anyway.

Endolf: I’ve been thinking about that, but if users get to pick their ‘display name’ I’m worried about people impersonating others. And if I start checking that the display name is unique then I might as well just use that as the login id and have an email attached as normal.

#11

I’d never type in my gmail username and password in some game!

#12

agreed, I’d never enter my google account details on any site other than the official google site.

Its way too easy to create a fake login screen and google links to way too much personal information (especially stuff like email, credit card info, adsense, etc).

#13

Custom login it is then :slight_smile:

Does anyone have any experience with having a user log in via a webpage and then passing that along to an applet? I assume I’m going to have to pass along some kind of authentication token which will link to a session on the server side, but I’d like to hear from people who’ve done something similar in the past.

#14

Sure. Get the username, password & netaddress from the login webpage, serverside validates the credentials then generates a session uid & embeds it in the returned applet page as an applet param. Clientside loads the applet which calls back with the uid, serverside then uses the uid & netaddress to veriify the calls & if all is well sends back the relevent data.

#15

Sorry i had to ask, if you require login details via a webpage and theres an applet running on it. why not just enter the details via the applet??

#16

I’m imagining that the user might play as a guest for a bit, then register in via the applet to save progress. At that point it would be nice if the webpage knew they were signed in at the same time so it could display their info and such.

#17

You could consider testing this: https://rpxnow.com/
It makes it less of a barrier for a user to authenticate, since no new signup is needed. IIRC you get confirmation from from RPX who the visitor is, and you don’t have to worry about it. I was going to test it for games4j.com, but then also keep info locally in my DB regarding nick and more. It is not optimal if you want to be able to authenticate after visitor started playing the applet, but I think even that is possible.

It is however very similar to stackoverflow, but that is working very well I think. One drawback is that the authentication process could look a little bit like a phishing attack. Maybe that is what you have against it.

I haven’t tried it and it was a while ago since I looked at it, so I am not sure it will fit your needs, but there is a free version and I think it is quite easy to hook up a simple version to test.

People really don’t want to sign up with email unless they KNOW what they get is something really good.

I currently do what SimonH described.