Case-senstive search of user profiles

[barpec12]

What happened?

After switching from Bungeecord to Velocity we have observed weird behaviour. Some premium players had their UUID overridden to a different UUID than before. It appears, that it might be possible, that username saved in database will differ from the one the player uses by case-sensitivity. For example: in DB there might be a user notch, but the joining one is Notch. The player profile will be matched, as searches in DB are case-insensitive. Bungeecord will generate UUID from the current player username, but Velocity from the player profile saved in DB.

Code in Velocity UUID offlineUUID = UUIDAdapter.generateOfflineId(playerProfile.getName());

Code in Bungeecord UUID offlineUUID = UUIDAdapter.generateOfflineId(username);

Quick fix would be to modify the logic for generating UUIDs for Velocity, but it does not solve the issue, that the username in DB might differ by case-sensitivity.

Steps to reproduce

I have not checked, how it happenned, that the username differs in DB. I suspect, that this scenario is possible:

1. Non-premium user joins from a username notch
2. Premium user (another or the same one after buying premium) joins with username Notch
3. Profile is matched, so the username is not updated in DB.

Plugin list

No response

Configuration file

No response

Server log

No response

Plugin version

master branch

Platform

Velocity

Relevance

• [X] I tried the latest build (build refers to development builds not necessary a release version; i.e. v1.10 is out of date)

• [X] I checked for existing tickets - If there are, please vote them with a thumbs reaction and not create new ones

[TuxCoding]

That's very good point. I think this would mean we should make the DB search case-sensitive, because the UUID will be different and this behavior simulates more a unmodified offline server.

However, this has downside a bad user experience, because I assume auth plugins including AuthMe are just converting the username to lowercase and save it as such in a single record. Therefore, the UUID and then inventory, etc. would be different. Nevertheless, we are in the position to change UUID during the login process including going out of spec with the potential to break plugins that really depend on it.

What is your opinion?

[barpec12]

That's very good point. I think this would mean we should make the DB search case-sensitive, because the UUID will be different and this behavior simulates more a unmodified offline server.

However, this has downside a bad user experience, because I assume auth plugins including AuthMe are just converting the username to lowercase and save it as such in a single record. Therefore, the UUID and then inventory, etc. would be different. Nevertheless, we are in the position to change UUID during the login process including going out of spec with the potential to break plugins that really depend on it.

What is your opinion?

I think, that most plugins are not made having FastLogin in mind, but more considering standard offline minecraft server behaviour, so it should be kept by default. UUIDs on offline server should be the same before installing FastLogin, after installing it (when configured for offline UUIDs) and after removing it.

The problem with different inventory and AuthMe account would also appear when having AuthMe as the only plugin on the server (without FastLogin).

I think though, that there could be a customizable functionality in FastLogin similar to nameChangeCheck, which could check if there is a profile of the same name, but different case-sensitivity and update name in this profile. If this check would be disabled, the behaviour would be the same as in standard offline server.

[earlhsjks]

it's required to have database if you're using proxy?

[TuxCoding]

@earlhsjks This plugin always uses a database. Somewhere the user preferences and save data have to be stored. The spigot platform only allows to use single file database (SQLite) too.