Forum ‹ QuickConnect ‹ Using email as username

[wgfunstorm]

I tried to register users using Simple Users with their email as username but I receive an invalid username error. I assume this is because of the @ symbol because when I replace it with an _ it works. So when the user later tries to log in using their email, I simply do the same thing. The whole process is invisible to the user.

So my question is, does anyone else have any experience with this? Is automatically replacing the @ symbol with an underscore the best way? Can you think of any reasons this is a bad idea? What other characters are supported as part of an email address but not as part of a username? Am I simply going to have to trial and error these? I couldn't find anything about it in the documentation.

[Henrik]

Oh, you want people to just register with an email address, so you get both username and email in one go? We didn't think about that.

The reason the usernames are restricted is that they are also the keys to objects in the BigDB PlayerObjects table, and object keys are pretty restricted to ensure they are in a format that can be safely passed through all the various client libraries. Basically, an object key can only contain alphanumerics. '-' and '.', and no other special characters, so '@' or '+' and '_' are not allowed.

The problem with substituting characters is that you can potentially get collisions, but in reality you most probably won't. You can make collisions even more improbable by appending a short hash of the email to the username. So for example you could get the following usernames:

example@one.two.com -> example.one.two.com-12345
example.one@two.com -> example.one.two.com-83272

...but I don't know how hard it is to calculate a short hash in AS3.

[Benjaminsen]

Henrik, you are making it way to complex .

First off, don't use emails as usernames, as QuickConnect uses the username as the userid of said user. IE QuickConnect users user ids are simple[username]. Thus unless your super careful you will be sharing peoples emails with everyone.

When that is said, QuickConnect already supports people logging in with their email. Thus you can just dump something random into the username field. Personally I use a GUID in Everybody Edits, but you might be able to come up with something more clever.

[dreamora]

we use mail as one possible way in our game among other login paths (FB and in the option for twitter and others is there too) and then generate globally unique user ids from it.

Our solution to the problem is a simple mail.Replace("@","..") as thats a bidirectional replacement because valid mail addresses can't have the dot twice without another letter in between.


replacing it with the underscore would work but it wouldn't allow you to reconstruct the mail address correctly anymore as underscore is an allowed letter in the mail address.

[Benjaminsen]

we use mail as one possible way in our game among other login paths (FB and in the option for twitter and others is there too) and then generate globally unique user ids from it.

Our solution to the problem is a simple mail.Replace("@","..") as thats a bidirectional replacement because valid mail addresses can't have the dot twice without another letter in between.


replacing it with the underscore would work but it wouldn't allow you to reconstruct the mail address correctly anymore as underscore is an allowed letter in the mail address.

If your creating your own authentication system, you should not really use QuickConnect. Rather what you are looking for is the connections api at http://playerio.com/documentation/connections

Additionally an underscore will not make 99% of the emails hard to guess. IE user_gmail.com is not exactly hard to figure out.

[wgfunstorm]

'@' or '+' and '_' are not allowed.

_ works for me. I double checked and the user was added to the database with an _ in his username. Maybe a bug?

you will be sharing peoples emails with everyone

Yikes, definitely don't want to do that thanks for the heads up!

When that is said, QuickConnect already supports people logging in with their email. Thus you can just dump something random into the username field. .

Doh, shoulda just tried it. You're right it works perfectly fine.

[dreamora]

Thus unless your super careful you will be sharing peoples emails with everyone.

And how would that happen?

[Benjaminsen]

Thus unless your super careful you will be sharing peoples emails with everyone.

And how would that happen?

A very typical use-case of Player.IO is to allow clien-side reading of Player.IO PlayerObjects for friends-lists etc. You would not be able to implement this if you exposed the users email via their connectUserID.

[dreamora]

depends on the game I guess.

If its not an FB game but an email login (as in draw something), one where you can only invite friends through sending mails, then you obviously know the mail address already and its no longer a topic

I personally don't consider that a typical usecase either.
Why load the same data twice (playerobject), if I can load and cache on the server and only feed the client with the informations he really needs to have, while protecting security relevant informations. that out of my view are two use cases against loading it from client (traffic optimization, security basics)

Would be like calling 'requesting DB Objects with only selective attributes filled' a common use case.
For our purpose it is but obviously not for all assuming that BigDB lacks this basic feature to reduce bandwidth & traffic requirements especially on loadrange.
Or the lack of an $or counterpart to check for multiple fields in parallel under OR constraints without having 1 index per attribute in the or + doing each of the requests on its own getting X times the data (if we want the first 10 that fullfill a or b or c or d, thats 4 requests each with 10 -> 40 objects instead of 10) that we need to process again to get it down to what we actually wanted to get right from the start.

These things currently enforce server side caching to be used anyway to do these operations performantly and traffic efficientely.
Yes it means more time investment than going with BigDB, but I don't see reasonable options to avoid it without accepting an uncalculateable risk on the traffic cost side or replacing Player.IO as whole and going with NodeJS + Mongodb / cassandra / neo4j or going with Moai