PSA: The Switch to UUIDs - Potential Plugin/Server Breakage

Discussion in 'Community News and Announcements' started by EvilSeph, Mar 30, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    EvilSeph Retired Staff

    At the beginning of the year Mojang started dropping hints of their plan to switch from a name based accounts system to a universally unique identifier (UUID) based accounts system, ultimately moving towards allowing people to change their Minecraft name. With much of Minecraft currently relying on a name based accounts system (bans, whitelist, ops to name a few) along with plugins using names to keep track of players (permissions, ownership, protections), this change has a high potential to break both plugins and servers if server admins and developers are not prepared for it. At the time of writing, Mojang have said they're planning to enable name changing around the time Minecraft 1.8 is released and with Minecraft 1.8 slated to release in May, the window for preparations is quickly closing.

    What is a UUID?
    A Universally Unique IDentifier is a fairly long series of hexadecimal numbers commonly used in software to uniquely identify something. With Minecraft, Mojang is planning to use UUIDs to identify player accounts, with each Mojang account tied to a UUID. For example: Notch's account now has the UUID "069a79f4-44e9-4726-a5be-fca90e38aaf5".

    Potential Server Breakage
    Up until this switch to UUIDs, Minecraft has relied on names for many of its core systems (bans, the whitelist, ops, etc.) and plugins have used names for permissions and protections. Once Mojang allow players to change their names at will with Minecraft 1.8, these systems’ accuracy can no longer be relied on. For Minecraft, Mojang have said they'll be handling the transition of bans, whitelist, etc. for the most part, but most Bukkit plugins will need to be updated to use UUIDs to track players instead of names.

    To prepare servers for the switch to UUIDs, server admins should perform an audit on their plugins to determine which ones currently use names for player identification. It is recommended that server admins communicate with the developers of the plugins that they use to ensure that they're preparing for the switch to UUIDs. The types of plugins that will likely be affected include (but are not limited to): permissions, region protection, world protection, chest protection, ownership, teleportation, economy, chat, and ban management plugins.

    Basically, it comes down to this: neglecting to prepare for the switch to UUIDs is the equivalent of running your server in offline mode. With player names no longer being static, anyone could potentially pick up an Admin's username and take over your server or bypass your protections.

    Plugin Developer Considerations
    Yesterday (March 29th, 2014) we went live with our UUID migration plan (Bukkit commit, CraftBukkit commit), where I made the decision to make use of Java's deprecation system as a means to get the attention of our plugin developers and make sure they're aware of the problems this switch to UUIDs is going to cause. This deprecation sweep was intended as a companion to this article. Information on this switch to a UUID based system has been hard to come by, with the majority of it coming from tweets from Mojang. As a result, while we have somewhat devised a migration plan, it is purely based on guesswork and assumptions which could be far off the mark by the time the system goes live.

    Points for Developers to Consider:
    • Names will no longer be a unique identifier for a player
    • String based lookups still work, they've just been deprecated to raise awareness of the upcoming changes. Some of the deprecations will be removed in the future. See our Current Migration plan below for more information.
    • Any data stored about users should be updated to use UUIDs
    • Since Minecraft 1.7, a player's UUID can be acquired through Player.getUniqueId();
    • Server.getOfflinePlayer(UUID) is a blocking, inefficient temporary hack provided for you to prepare a migration plan of your own.
    • You need to use Mojang’s AccountsClient or evilmidget38's UUIDFetcher (recommended) to convert Name to UUID. We may or may not provide our own built-in solution for this.
    Our Current Migration Plan, for reference:
    Minecraft 1.7.5
    • Deprecate string based player lookups to raise developer awareness of the switch to UUIDs and the impact it would have
    • Add a temporary hack to allow for early support for name lookup by UUID, which is currently inefficient and blocking
      • This is provided for plugins to prepare a migration plan of their own and NOT for use in production.
    Minecraft 1.7.6+
    • UUID lookup will become the most efficient lookup method: check if UUID matches stored player data on disk
    • Name lookup will then become the least efficient lookup method
    Minecraft 1.8
    • UUID awareness deprecations will be removed as time for preparation has passed, if they haven't been removed already
    General Notes:
    • A Mojang account is required if you want to change your name
    • Names need to be unique; you can't change your name to one that is already in use
    • Name changing is free but will probably be limited in some way to prevent abuse
    • If you haven't migrated your account to a Mojang one, you should do so as soon as possible to secure your name
    • Name changing is slated to go live when the web service has been updated and around the time Minecraft 1.8 releases
    • Once you have changed your name, your previous name is now up for grabs. This is not a traditional local nickname system, it is a global claim-based system. It is unknown if there will be a grace period or any protection against name sniping.
     
  2. Very insightful, thanks!
     
    Marten Mooij and Aengo like this.
  3. Offline

    Borlea

    Hope this answers peoples questions.
     
  4. Im guessing this will be a nightmare not just for developers and the bukkit team, but also people running craftbukkit servers?
     
    DoggyCode™, fussionzz97 and danw3st like this.
  5. Thanks for clearing this all up :)
     
  6. I knew a change similar to this was going to happen when I saw it in the patch notes of a MC update. Well be interesting to see how this turns out(for the MC community and Bukkit).
     
  7. Jeez, need to recode almost everything now, thanks Mojang.
     
    htmlman1, Cro007, Evildude221 and 8 others like this.
  8. Offline

    nightpool

    So glad to hear this all be cleared up! A lot of people are watching the github repo, and the communication there can be a little confusing some times.

    (I'm got some additional thoughts/questions along that line, but that's a different thread...)

    Depends on how Mojang does their transition, and how competent/active/committed/good at thinking things through individual plugin developers are.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
  9. A bit conflicting....
     
    satisfiction likes this.
  10. Offline

    TnT Retired Staff

    Anyone can change their name. Which means anyone can pick someone's former name as their new name.
     
    MaliciousMan and KingFaris11 like this.
  11. Offline

    Shuski

    If an admin changes their name, another user can potential take the Admins previous name, since non-updated plugins are running on usernames for id, and now they have access to an admin account.
     
  12. EvilSeph
    Quick question, how long would a UUID be? For storing in SQL databases purposes.
     
  13. mazentheamazin
    Hexadecimal is usually 16 characters. since its a combination of numbers and letters, the amount of combinations is really high, so there isn't a need for the length to change. If you aren't sure, you can always count Notch's UUID's characters. =P
     
  14. Gamecube762
    After a bit of research, I found out that it is 36 characters (including dashes). Quoting 'broofa' from stackoverflow
     
  15. Please do! Delay the release by a bit and do this for us, developers would appreciate it a lot since it makes life easier, e.g. Bukkit API does a lot.
    Server owners may get slightly annoyed by waiting, but I'm sure it won't take too long and it will benefit them in the future.
     
    biel likes this.
  16. Offline

    isokissa3

    This breaks custom names for scoreboard?

    Code:java
    1. Score score = objective.getScore(Bukkit.getOfflinePlayer(ChatColor.GREEN + "Kills:")); //Get a fake offline player
    2. score.setScore(0);
     
  17. Name lookup made the most inefficient?
    Is this just having to poll all player files, or pinging mojang for name to uuid conversion.

    If the latter, won't that screw every command that takes player names?

    I don't expect an admins would like having to wait for a http response when typing /ban asshatmcgriefer
     
    MaliciousMan likes this.
  18. Great, so i start adding a minigame to help my players memorize their UUIDs, so they don't get confused with ingame-money transfers later on.

    I think Mojang should just make signs hold 16 characters in a row :p.

    It can be terribly confusing - i assume server owners will be forced to switch to "this server only" display names, and maybe even to add a "remember past high level staff display names and prevent others using those by forcing them to register another nick" thing.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
    MaliciousMan likes this.
  19. As this:
    Code:java
    1. getServer().getOfflinePlayer(<UUID>).getName()

    is terribly slow, what is the best method to get a player's name from their UUID for display purposes? Will this be more efficient?
    Code:java
    1. public final String getPlayerName(final UUID uuid) {
    2. if (uuid == null) {
    3. return null;
    4. }
    5. for (final OfflinePlayer player : getServer().getOfflinePlayers()) {
    6. if (uuid.equals(player.getUniqueId())) {
    7. return player.getName();
    8. }
    9. }
    10. return null;
    11. }

    (assuming the player has joined the server before but is not online)
     
  20. Thanks for the heads up, but Mojang has went to far in changes now. :(
     
  21. I think the best solution is to "protect player names" with some authentication plugin. This way you use your "server account" instead the Mojang account, and can save your player without recode all the plugin. Fuck the world :)
     
    snivell likes this.
  22. Wait so I was a bit confused will bukkit allow for UUID --> Playername? I hope so for death messages and such!
     
  23. The Fancy Whale

    I think you would have both Player.getName() and Player.getUUID(). The first to send messages, dispaly names... and the second to store infromation like perms, money account... We developpers will have to recode many many lines, or, as i've saying before, have a nice auth plugin in all servers hehe.
     

  24. If player is online, then yes. Don't worry, we won't be seeing UUIDs instead of player names in death messages and such-like. This is just for when plugins need to store information, they should now use UUIDs as usernames will be able to change soon.

    Also, if servers need extra time to prepare, a way to do it would be to use this plugin temporarily. Although I would recommend switching asap. http://dev.bukkit.org/bukkit-plugins/oneuuid/

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
    The Fancy Whale likes this.
  25. Does this mean there will be a bunch of five year olds with youtuber names? Awww crap
     
    superguy9 and Werioco like this.
  26. Only if nobody else is using that username
     
    MaliciousMan likes this.
  27. I am making a new land protection plugin. The problem I had is to assign a land permission to a user. It is not user friendly to ask the user to find out the big UUID and enter it as parameter instead of the player name. For now, I can not know the player's UUID when the player is offline or never connected to the server.

    My solution:

    • The user adds a the offline username in a parameter (Land owner, land resident, build permission in a land, etc.)
    • A local UUID is created and assigned to the user name in a association database.
    • The reference in the land database is the Local UUID.
    • The next time that user will log on, the plugin will get the Minecraft UUID and will be added in the association database.
    • If at a next logon, that user as changed is name, the user name will be update in local UUID database.

    The UUID database contains (must accept reverse lookup):

    • The name of the user (updated at the last log on)
    • A local generated UUID for the user (for internal plugin reference)
    • The Minecraft UUID for the the user (added when we know it)

    Example 1:

    You ask the plugin who is the owner of the land :

    • Land Database --(local player UUID)-->UUID local database-->(player name)-->Player name send to you

    Example 2:

    Is the user has access to build here? :

    • User build permission check --(Minecraft player UUID)-->UUID local database-->(Local player UUID)-->Land database

    Limitation:

    The only limitation I found is if a user change his name AFTER he was created in UUID database and BEFORE his Minecraft UUID is know.
     
    biel likes this.
  28. Offline

    Black Hole

    Use Mojang’s AccountsClient to look up the UUID for a player name. But it's returning the UUID als a String only. And in a format the UUID class don't understand. So you have to insert the dashes on the right places and use that.

    Most database systems have support for UUID data types. So they store it in 16 bytes and the look up will be a bit faster than string look ups.

    With the deprecations being removed with Bukkit for Minecraft 1.8 these commits finally makes sense. :)
     
  29. mblanchet75
    Bukkit.getOfflinePlayer(name).getUniqueId().

    I think this update (at least in the current form) will fuck up offline servers a bit. The getOfflinePlayer(UUID) does not work, when you put in a offline-UUID. I think this will change when the server side cache is implemented but as of now, plugins relying on this will not work properly in offline mode.

    Not that it matters that much, but if you run your testserver in offline-mode, you should switch now.
     
  30. Offline

    MrLizardDogMan

    Mhh, I feel like this is going to be worse than the 1.7 update, It'll take a long time to get all the plugins updated to use the new name system. Many servers will stay 1.7 until their plugins are updated, which could take months. If the player can change their name through the Mojang Website, this means that there is no stopping it until we can update our plugins. So until then, we just have to hope it would only pertain to 1.8.
     
Thread Status:
Not open for further replies.

Share This Page