Support for Premium username change

[TKwSni]

Just as a reminder

If premium player Joins with a different name after he played at least once in the server an error of duplicate entry is shown in console since you cant have more than 1 row with the same uuid.

A temporal fix is to remove the unique index from the uuid rown in the database, this will allow duplicate uuids and let the player play normally. The only thing I can imagine that could happen, nopremiums player wont be able to use that nick and if by any chance a premium player gets that username and try to join the server with it, the uuid row gets updated with a new uuid without errors.

[TuxCoding]

Linking my spigot post here: https://www.spigotmc.org/threads/fastlogin.101192/page-8#post-1577901

->Examples:

Case 1

nameChangeCheck = false
autoRegister = false

Player logins as cracked until the player invoked the command /premium. Then we could override the existing database record.

Case 2

nameChangeCheck = true
autoRegister = false

Connect the Mojang API and check what UUID the player has (UUID exists => Paid Minecraft account). If that UUID is in the database it's an existing player and FastLogin can assume the player is premium and changed the username. If it's not in the database, it's a new player and could be a cracked player. So we just use a offline mode authentication for this player.

Limitation: Cracked players who uses the new username of a paid account cannot join the server if the database contains the old name. (Example: The owner of the paid account no longer plays on the server, but changed the username in the meanwhile).

Case 3

nameChangeCheck = false
autoRegister = true

We will always request a premium authentication if the username is unknown to us, but is in use by a paid minecraft account. This means it's kind of a more aggressive check like nameChangeCheck = true and autoRegister = false, because it request a premium authentication which are completely new to us, that even the premium UUID is not in our database.

Limitation: see below

Case 4

nameChangeCheck = true
autoRegister = true

Based on autoRegister it checks if the player name is premium and login using a premium authentication. After that fastlogin receives the premium UUID and can update the database record.
Limitation from autoRegister: New offline players who uses the username of an existing minecraft cannot join the server.

What should happen if the username is use of an cracked player?

@Blackyvk The fix you described is for the UUID column, but what about the unique index for the name. It's possible that a paid account changes the username to a existing cracked one. My thought is that we in this case cancel the save process and send the user a message like:

This username is protected for a cracked player. If this is your account authenticate with your password and type /premium.

[TuxCoding]

Sorry for the big delay. I was too busy with other things.

[TKwSni]

dont worry, i was using "my temp fix" meanwhile, Anything special i need to know before trying this ? beside deleting the duplicate uuid rows generated.

[TuxCoding]

Anything special i need to know before trying this ? beside deleting the duplicate uuid rows generated.

Not really. If the option nameChangeCheck is enabled it will make an additional check if the uuid is available in the database. Then if FastLogin wants to save the new record into the database it will run an update query first. (UPDATE premium SET Name=? WHERE UUID=?). If no rows were affected by this query, it will continue to insert a new database record.

But can you change your name back? If so, fastlogin wouldn't know this user.

[TKwSni]

Tested and noticed few things. Before I started, I added again the uuid unique index and deleted the duplicates.

Authme sessions = disabled
autoregister = true

• New cracked players arent registered to the database.
• if nameChangeCheck = false and a premium player logs with new name (that isnt registered) the name row is updated and register/logs normally ( i think thats how its supposed to work )
• if nameChangeCheck = true name row isnt updated but you can play normally but, you get a (auto registered with = xxxx) every time, different password.
• if nameChangeCheck = true and premium player (with new username) tries to logs in as a already registered cracked player, I get this error in console http://pastebin.com/pnwtJLkD

If I authme sessions = enabled

A premium player can log in as cracked player already registered. I tried to /logout many times, but after coming back I always get logged in somehow. ( i didnt test this before this update )

The way i test the name change is by simply changing the database name row with a new name and (registering/unregistering the account from authme) . For cracked check is just adding new records as premium 0 with the premium username. I think its ok to test it like this.

I also noticed that you changed some things to the database in ( this commit ) things like Name are now just Name, does that matter somehow ? is this something needed to change in the database structure ? because whenever i type mysql queries these are autocorrected from Name to Name for example.

edit: Name = backtick Name backtick

[TuxCoding]

A premium player can log in as cracked player already registered. I tried to /logout many times, but after coming back I always get logged in somehow. ( i didnt test this before this update )

Could you try it without FastLogin?

[TuxCoding]

if nameChangeCheck = true and premium player (with new username) tries to logs in as a already registered cracked player, I get this error in console http://pastebin.com/pnwtJLkD

This error occurred because the UUID is incorrectly formatted.

[TKwSni]

Ok, those two , 1 is authme (maybe be cause i'm on the same ip always) and the other one might be one of the records I created and added a bad uuid, i forgot about that. So the only problem now is the cracked players not being registered in the fastlogin database i guess.

[TuxCoding]

Ah I found the source. I'm working on a fix.

EDIT: It happens too, if the user has autoRegister disabled.