Hold users in DB and users have to sign on with a password

[LevelX2]

This issue gathers advantages and disadvantes and possible features if we create a database with users and users have to sign on with password to verify identity.

Questions

• Should it only be possible to log on with existing profile or is also allowed log in without profile like now (but I guess it would be easier to assume a profile to make implementation of new features easier).
• Should be email verification be done to create a new profile

Advantages

• You username is protected to be used by other users.
• Reconnect with different IP/Host after disconnect would be possible.

Disadvantages

• You have to create a user profile before you can play.
• Server backup and server hack protection gets more important.

Possible Features

• Friendlist
• Show when a user was last time online.
• Show statistic about played games / quitted games / disconnets etc.
• Save some deck-lists on the server .
• Ban List for users

Feel free to add comments with additional thoughts.

[magenoxx]

oh, totally support the idea!
what can be also done: make security profiles so that it should be enabled explicitly so we have the same behaviour as now for devs and for players who download&play in single mode only - I mean no need to create profile and enter password for them

what also should be done is creating back up process (better automatically by cron) for db with possibility to copy to external source

[seedds]

great feature.

our ISP provider only support dynamic ip in China. This could finally solve
the reconnect issue.

On Wednesday, August 6, 2014, magenoxx notifications@github.com wrote:

oh, totally support the idea!
what can be also done: make security profiles so that it should be enabled
explicitly so we have the same behaviour for devs and for players who
download&play in single mode only instead of online&publicserver

what also should be done is creating back up process (better automatically
by cron) for db with possibility to copy to external source

—
Reply to this email directly or view it on GitHub
#478 (comment).

[JeffHoogland]

Why not offer user registration, but still have a "login in as guest" option?

[magenoxx]

it can be useful but how it is implemented now - guest won't be able to re-connect

[mike-code]

My proposition is public-private key authentication.
TeamSpeak 3 has introduced password-free authentication based on that method and I must say it works quite well. There's no problem with forgotten username/password. You are not bound to single username (you can use any as you are identified by your public key). You don't have to give any personal information such as e-mail.

The only disadvantage is that you have to teach users that they have to export their identity (pub/priv key) and store it somewhere in order not to loose their identity.

Sure, this doesn't prevent users from creating multiple profiles but registration doesn't either. Anyway, who would bother doing that? Also, people can decide if they want to play with newcomers based on number of games they played. You can also store number of games person abandoned (disconnected before the actual game finished).

[jeffwadsworth]

That would never work, unfortunately. Too much work for the average player.

From: Mike [mailto:notifications@github.com]
Sent: Tuesday, February 03, 2015 7:05 PM
To: magefree/mage
Subject: Re: [mage] Hold users in DB and users have to sign on with a password (#478)

My proposition is public-private key authentication.
TeamSpeak 3 has introduced password-free authentication based on that method and I must say it works quite well. There's no problem with forgotten username/password. You are not bound to single username (you can use any as you are identified by your public key). You don't have to give any personal information such as e-mail.

The only disadvantage is that you have to teach users that they have to export their identity (pub/priv key) and store it somewhere in order not to loose their identity.

Sure, this doesn't prevent users from creating multiple profiles but registration doesn't either. Anyway, who would bother doing that? Also, people can decide if they want to play with newcomers based on number of games they played. You can also store number of games person abandoned (disconnected before the actual game finished).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/478#issuecomment-72770732.

[mike-code]

What do you mean? Exporing identity is too much work? Nobody says they have to, if they don't and loose it, they'll be treated as "guests". Priv/pub key is generated on first run and doesn't prompt user to anything. Just like in TS3, you just run executable for the first time and default identity is generated by default. You just connect to a server and.. talk (play? ;) )

[fclarat]

I love it.

So you can ban, suspend or just see the stats a player who "disconnect" from a tournament all the time.

[LevelX2]

What's needed for a first implementation step:
Password reset
To be able to reset the password, if pw was lost. It has to be automated.
that would need email and confirmation...
Otherwise we will have all day complains about lost account.

We should add some more attributes to the new user DB

• Profile created
• Last login
• number of matches (by format?)
• number of wins/losts/draws
• connection losts
• number of tournament cancelations

Display in the user list if a user has a profile and a possibility to show the information from the user (like matches played etc.)

[menocar]

As an initial implementation I propose to start from a very simple authentication flow with a minimum user attributes stored (user names, hashed passwords and email addresses). Then we can start extending the functionality.

[Registration]

1. When connecting to a server for the first time, user opens up a sign-up dialog and inputs their user name, password and email address.
2. XMage server generates a token for an email address validation, sends it to the email address and also store it to a temporary DB. The user name, (hashed) password and email address will also be stored to another persistent DB, with a flag indicating the entry is not validated yet.
3. User enters the token to XMage. The entry in the temporary DB is cleared and the entry in the persistent DB is marked as validated. Now the user can log in with their user name and password.

[Resetting password]

1. User enters their email address to a password-reset dialog.
2. XMage server generates an authentication token, sends it to the email address and stores it to a temporary DB.
3. User enters the token and a new password to the password-reset dialog.
4. XMage updates the persistent DB entry with the provided password.

Things that need to be implemented In addition to the current pull request:

• New dialogs for sign-up and password-reset.
• Email address validation functionality. This can be shared by both of the flows.

Things that are not included at least to the initial implementation:

• Encryption of server-client communication. So password is visible if a user is in a same network as another user.
• Account sync among servers. User needs to register in each server.

Please let me know if you guys have thoughts on it. I'll start implementing above shortly.

[mike-code]

I still propose pub priv key auth with keys being generated during first run. No logins, no passwords, no forgotten passwords.

Cons (for me its advantage tho) are: users can change nicks as they wish but are still bound to their pub key and moving account to another pc requires more than remembering email and pass (you have to export/import private key either via txt file or clipboard.

Also huge advantages are that you dont store any private data (such as email) and the auth works without any forms

[menocar]

Hi Mike,

The way how TeamSpeak 3 authenticates provides a very high security integrity level at such a low cost, which is great, but I'm not sure if we need it for XMage. Other points don't seem essential to me, we register web services all the time so another registration shouldn't be a huge cost.

I still prefer us start from a simple authentication system. We can switch to a more sophisticated system once it's ready.

[fireshoes]

The current system currently refuses reconnection for a username if your IP address changes, so I appreciate if that gets eliminated with the username/password system (I have to use cell service to connect so my IP address changes if it loses signal for any amount of time, so I get booted from games pretty regularly).

[LoneFox78]

Obviously(?) this needs to be optional, so that developers and contributors don't need to setup accounts on their local servers. Also, there seems to be more code already for setting up that external library and its user repository than it would take to implement the whole thing without any new dependencies.

[LevelX2]

It could be of course a useful option to be able to activate/deactivate user authentification in the server config.xml.

[menocar]

fireshoes, yes, we should be able to do the identity check using authentication information rather than IPs.

LoneFox78, good point. User DB is kept across updates so it'll be one time cost but it's still a pain. It's useful to have a server option to skip authentication.

[LevelX2]

LoneFox78, good point. User DB is kept across updates so it'll be one time cost but it's still a pain. It's useful to have a server option to skip authentication.

So it would still be possible to run xmage servers without the need to create profiles (e.g. in a local network).

[menocar]

Let me close this issue as the implementation is completed. Starting from the next client/server release:

• We are going to enable password authentication.
• When authentication is enabled, user auth information is used for reconnect, rather than IP.
• Match histories are going to be recorded persistently. We'll compute user stats based on that and show the information next to the user names in the main frame.