More precise server user control

[iffrizat]

What is this PR about?

As an xmage server owner I noticed that the current user management system allows virtually anyone to play, whether the registration is enabled (anyone can just create an account and play) or not (anyone can still login and play). I found myself in need of a more precise user control mechanism.

What does this PR change?

• authorizationEnabled switch in the server config has been replaced with 2 others - registrationEnabled and checkUsers. The former controls whether any user is able to register, the latter controls whether the server has to check a user's credentials against the authorized_users.db upon logging in.
• authorized_users.db's back-end has been changed to sqlite, instead of H2. This was done because it allows for simpler integration with 3rd-party tools, as there exist many more drivers for sqlite. This will probably break all existing servers, as the authorized_users.db will have to be migrated to sqlite. I can imagine, this change can be dropped if the xmage server is shipped with appropriate tools to modify an H2 database.

Why is it useful?

It allows for server owners to prevent unwanted players from joining their servers as well as more precise control over existing players.

Thank you for your time!

[JayDi85]

h2 database has admin tools to view and modify db content, see http://www.h2database.com/html/quickstart.html

[JayDi85]

I don’t test it but disconnect another instance of the user is very important for xmage game engine (it can work with single user’s instance only). There are must be 1 user per player (registered or anon — each mode must keep single user). So game will see only 1 user to send and wait feedback.

On login logic:

• in registered mode: disconnect all other user instances;
• in anon mode: disconnect all other user instances if it’s same host (ip address).it’s important to restrict login with same name but diff IP (e.g. you can’t disconnect another logged user).

So user instance consistency must be enabled all the time. No need to setup it.

[iffrizat]

Thank you for pointing that out!
I will do some testing on my own as well.

[JayDi85]

BTW it can be good to have independent registered and anon modes. So users can register or login with any names (except registered names).

[iffrizat]

h2 database has admin tools to view and modify db content, see http://www.h2database.com/html/quickstart.html

Apologies, my bad for not seeing that, I will revert the transition to sqlite.

[iffrizat]

BTW it can be good to have independent registered and anon modes. So users can register or login with any names (except registered names).

My problem is that I only want my friends to play on my server. With the current system, pretty much anyone can use the server to host their games, unless I am missing something.

[JayDi85]

With the current system, pretty much anyone can use the server to host their games, unless I am missing something.

If you enable registration then only registered players can be played. Registration requires email usage (server send special code by mailgun service to confirm it).

As workaround 1:

• enable registration and enter mailgun in config, wait all friends registered;
• keep registration, but delete mailgun — so no new registrations will work (no codes on email);

As workaround 2:

• edit database file and add users manually by h2 admin tools (see link above)

As workaround 3 (I recommend it):

• generated auth database by code, see example in https://github.com/magefree/mage/blob/master/Mage.Tests/src/test/java/org/mage/test/serverside/DatabaseCompatibleTest.java
• just add additional unit test with db generate and run it by IDE or command line, see instructions in wiki: https://github.com/magefree/mage/wiki/Development-Testing-Tools#unit-tests-from-ide

[iffrizat]

Thank you so much for these suggestions, but don't you think that a more streamlined user control system, that doesn't require workarounds, would benefit the project as a whole?

My point being, it would be simpler for server holders to tweak 2 values in their config as well as to open up H2 admin tools instead of having to bootstrap an IDE or Mailgun to just add an authorized user, wouldn't it?

I tested the implementation with a couple of friends, and it seemed to work fine. I didn't test trying to log in via the same credentials while a user with the same credentials is already logged in, but that is on my to-do list right now.