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


    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. Offline


    Got some good news :) I read mojangs page about uuids and changing you name only applys for 1.8 NOT 1.7 so lets say someone changes there name from test123 to test12345, there name will be changed to test12345 in 1.8 and it'll stay as test123 in minecraft 1.7
  3. Offline


    That's definitely interesting news. Where did you see that?
  4. Offline


  5. Offline


  6. Offline


    I think you must have misread something. I can't find anything in the link you provided that would make me think of what you had posted, especially considering it's impracticality.
  7. How about fixing MetaData to persist through restarts? Like it was originally designed to do.

    Then at least we have a method to store UUID to name relationships on an object so it only lasts as long as the object.

    Not unanimous by a LONG shot.

    Also NOT easy to code for. UUID's are not the same as a user name., they are not human readable. You can't go talking to someone in game called 213123-12312-213-123-123-1332 blah.

    There are plugins which will not be able to make the transition to UUID's. One such plugin is Lockette.
    I'm the maintainer of Lockette and the way it is designed is to require no back-end database.
    In this instance a UUID is useless. It's not humanly readable and can't be converted to a username by the player.
    Sure you say, just implement a database, but that's the whole point of Lockette. It's lightweight and doesn't need a database. Adding one would require so many checks and balances just to make sure it remains upto date is crazy.

    Lockette will be dead unless players use the plugin that locks a UUID to a player name.

    I also dev Towny and GroupManager, both of those will convert to the UUID system, but it's far from easy and it make the server owners job FAR more difficult once they can't easy tell who's data is who's in the files.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jun 7, 2016
  8. Offline


    Why is this an issue? It's fairly simple to add a username field under the UUID, if you need to store information. This also has almost no affect on MySQL databases, other than adding a UUID field, and making it primary.

    As far as lockette goes... You're right, there isn't much you can do there. :/ Maybe with this update, Mojang will fix the janky metadata, and you could make it human-readable by just having the UUID stored to that, instead of the sign itself.

    EDIT: I meant instead of the 'readable' part of the sign.
  9. Offline


    I was thinking the plugin could store both the UUID and "last known username" in the data files to allow us humans to read the files easier. The Last Known Username (LKU) could be updated on plugin startup and whenever a user logs in.
  10. Offline


    Way too much sacrifice, changes and broken plugins just for the sake of name changes. I never want to change my name. This whole thing is just a huge inconvenience
  11. Yes that's how it will work, however finding the right file will be no simple task anymore.
    Currently each player has their own data file with the same name as their character. Now each file name will be the UUID, meaning masses and masses of almost identical looking files with random numbers for names.
    To find a players data file you will have to lookup the las know player name in an index file and pull the coresponding UUID. Then go searching the files for that hellish string.

    The only people who actually wanted this are people who chose stupid names in the first place or made a mistake in their name.
    There was a third group, the grieffers, who thought being able to change their name would get around bans and give them back their anonymity.

    For the first group I say it's a life lesson, one that will never be learned if we keep catering to people who pick stupid names and regret it later.
    For the second group, sorry but there are already ample alternative with plugins which provide nicknames.
    For the third, tuff!

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jun 7, 2016
  12. Offline


    What I think would be beneficial is that every time a player logs in, their UUID is downloaded onto the server and stored in a local database. That way you don't have to poll outside of the server every time you do something with player names.
  13. Offline


    In groupmanager you could make it so it shows the name and UUID still and have the name update. Also since im a user of both towny and groupmanager what is the expected update time? My server completely is permission run since my custom plugins use it kinda like a database.
  14. Offline


    I think EvilSeph said earlier in this post that this would be a part of Bukkit, unless I misread it. He said they were storing last known username already.

    EDIT: Post #136
  15. Simple Question: What's with 1.6.4? Do I have to Update to 1.7.2 (Beta) or is the API of 1.6.4 udated for UUIDs?
  16. Offline


    I think that "offline mode" servers will not work properly now.
    Cracked players(Players with custom launchers) wont have UUID and wont be able to save their accounts, money etc. on servers if plugins change to UUID(which will happen in a few weeks) and it really sucks because I have a offline mode server for people from Serbia, Croatia, Montenegro, Bosnia and these people(most of them) dont have Premium accounts and dont want to buy them..
  17. Offline


    ElgarL wrecktify
    At first, I was like "oh no, this will break evrything in mah plugin!" But now that I actually got around to re-writing it... Not much has changed. A simple MySQL table holds the player name->UUID pair, updates every time someone logs in, allowing for OPs to easily and fast ban wrong-doers.

    I don't think it will even be necessary to query Mojang servers - as long as you keep a local index of players, virtually everything (economics, mailing, baning, notes) will be assigned to the last known name and stored using the UUID, which doesn't change and is easy to access!
  18. Offline


    That's pretty much what I'm doing. I query Mojang's servers soley for the purpose of upgrading the database to fetch UUID's for existing players... a one time operation. Once the database has been updated, I never ask the mojang servers for anything. That said, it won't fit every scenario, if the last known name gets added to Bukkit that will be less I have to store in my database but my plugin only asks for online users right now and only uses last known names for commands and messaging.

    The only real failure in this system is for "sign" based plugins like Lockette. That's unfortunate, but it is what it is. The freight train is coming and it can't be stopped by complaining about it, so we have to adapt.
  19. Offline



    Not that Bukkit supports OfflineMode, and therefore we don't care... but OfflineMode servers should work just fine.

    In the case that your serve is in offline mode, an MD5 hash will take the place of the username, generated using the username as the passphrase.
  20. Offline


    FerusGrim They won't, since if the player changes his name, the hash will change as well, making it utterly useless and unreliable for any kind of data storage.
  21. Offline


    Everyone's always been able to change their name in OfflineMode, meaning using anything as any kind of data storage has always been useless. No change, there.
  22. Offline


    I don't WANT to pay for gasoline, but, I have accepted that if I don't, my car ain't going anywhere. The heartaches of an offline server for the "I don't WANT to pay" groups should get but a tiny bit of sympathy at best.
  23. Offline


    Doesn't get much sympathy from me. My plan for offline servers is to simply wipe the parts of the database that are compromised. I have absolutely no intentions of attempting to convert that data and DEFINITELY don't plan to develop a second code path to handle names for those servers. They are just going to have to re-do.

    I'm sorry I just realized this got missed. 1.7.x implements Mojang's UUID. 1.6.4 had hashed UUID's and that data is not compatible.
  24. I heard rumors that old versions will keep the old names - no guarantee, because i did not check the official statements by Mojang, or maybe i forgot that i did. That would be pretty cool and buy us a lot of time, if needed.

    I am not sure if everybody shares the view of this being an acceptable risk. There are quite some staff members or just very active and/or very rich player who will change their names, so there certainly will be collisions, also "just for fun". So assume the new players getting a bit of shop money and such ~ "Jeb for a day!".

    My solution will probably need me to fork all plugins that use signs (or replace them) in order to have those query a trust-service-plugin. So names will be ok, if the player is still the original player, otherwise it will provide per-server tokens for use with economy/signs. The trust plugin will also provide checking for name changes and history of uuids, names and also check for collisions and such.
    That's just my current line of thinking up some "solution", it might still change around a bit (including considering sending fake sign changes or chat messages putting in names :p, etc.).

    Not just signs! I think i gave some examples above, like referencing offline players and the user interfaces for that.

    Did not want to edit this in: It also goes for more everyday stuff than just block/container protection, e.g. economy, shops, warps with shared access, lifts and anything like mechanisms that trigger with owners/restrictions, region trading (despite not knowing exactly what WorldGuard will do), mail, region plugins and convenience commands for the named, knowing there are more similar cases.

    Of course some could just use uuids internally, but you will have to map a name to a uuid for offline players, and it better be the right player who is referenced, otherwise there will be unpleasant surprises. That is why now the cautious player might want to know if the player being added is the player they know and trust - that's already not so simple anymore, specifically because then plugins need to check for different kinds of trust-levels and such - also many commands would have to be run asynchronously to actually really check offline players uuids. There are many variations to do something similar, including not updating offline uuid mappings with every interaction (would have to cancel the action until lookup is done...), but with some timeout on offline consistency checking. Using the last known names is less work, but also leaving quite some area for attacks and confusion.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jun 7, 2016
  25. Offline


    All of that can be converted to use UUID.

    No room for attacks. Last known names would have to be unique. If a player changes his name and while he still hasn't logged on you decided to add him to your op list by name (just an example, really not something we have to worry about), the wrong name would still correlate to the right UUID! Next time the player logs on this name would need to be changed. If another UUID logs on with that name, it would need to be removed from the other player that used to have it.

    What would be really beneficial if someone made a plugin that simply LOGS the fact that a user logged in with a name assigned to another UUID, or a UUID logged in with a name that wasn't the last know user. That way ops could see when their players change their name. Though, I wouldn't do this until we have confirmation that Bukkit will have a last known name option in the login event. That would be the best way. (I'm not going to do this, if someone wants to you have my blessing to run with the idea)

    I'm going to stick with my original statement. Sign based plugins are the only sacrifice here.
  26. Offline


    And might not have to be, if Mojang fixes its metadata system for sign-like entities.
  27. Offline


    Is Meta Minecraft or Bukkit?
  28. Offline


    I thought this was interesting:
  29. Offline


    It's a weird issue in Minecraft. Meta doesn't... 'stick' to things like signs, very well.
  30. Offline


  31. Offline

    Alshain01 It's fully expected though, the UUID's on the Mojang servers will not be the same as UUID's generated by hash.

    Have you seen the 1.8 patch notes? I think they are moving away from using Metadata at all.
Thread Status:
Not open for further replies.

Share This Page