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


    Except the migration should be finished by the time Mojang allows user names to change. Read the article again, by 1.8 they will be removing the notification deprecations, your plugins should be up to date by then.
  3. Offline


    Boy, am I glad I use AuthMe Reloaded - practically I can just sit back and enjoy things how they were (and will be). :)
    You guys should start using it right away to have a flawless migration to the UUIDs! ;)

    P.S. Am I the only one who thinks Mojang went a little bit too far this time?
  4. Offline


    FYI that uses the same UUID system were talking about. They just have theirs done already.
  5. Offline


    Really? :eek:
    I can't login to my server if I change my Minecraft name, since it checks only the name, what gives? Or do I not understand (I thought I do) this UUID system?
  6. Offline


    179 lines of code using names is now 397 lines using a new UUID system I create in a mysql Witch I think is going to be the most efficient way here's a rough sketch of what I have

    Log in 1st time
    Generate LOCAL UUID
    Find minecraft UUID
    Find username

    Log ins after that
    Get UUID
    Get local uuid
    If matched continue if not change local uuid to global uuid
    Get the name


    You can change a person's local uuid
    Modified there inventory using global uuid
    Find there local uuid in game (because it should match the global uuid)
    Up to 10 trillion players can join a server until you run out of uuid


    Very ineffective
    If the player uses a cracked account the local uuid is set to -1 because it can not find a global uuid so every cracked account will have the same inventory and uuid lookup
    It isn't suppose to be done this way and will break with every snapshot
    It disables UUID auto checking from other plugins

    So far thats what I came up with
    For a patch for now I'm working on a database matcher using a 4 way check
    Global uuid / local uuid / current name / I give it a number from 1-1000000
  7. Offline


    Well, my idea is not to be forced to be ready at a certain point of time, i dislike the all-versions-outdated pushing :p - the point is that my uuid-database layer will prevent people from joining the normal worlds with changed names, so 1.7.5/6 legacy code still should be fine in theory. Now once again the whole point of trying to rescue legacy data potentially making sense, still is that uuids are reported correctly before players can change their names and uuids should not change ever, unless some tracking/transformation-api is provided.

    So if a player changes the name, the pair of uuid+name will not match the database entry (entries), thus the player can't play in my transition phase.

    I would have liked to invest time into something more useful than this stuff...
  8. Offline


    Too far? Or just too soon? I personally like the change. It will screw things over for a bit, but hey. We'll see where things go.
  9. Offline


    No, you can log in just fine. Quick glance at Github and it looks like AuthMe has already fixed theirs but you just need to make sure your other plugins have updated or players may possibly change their name to the former name of an admin and gain privileges in that plugin. Only asofold is talking about denying players access via his plugins, that is his choice, I recommend not using those plugins if you value your server's players.

    The whole issue is merely the off chance that a player who has privileges or owns land or something like that changes his name and not only loses the privileges/land/etc. but also opens the door for someone else to change their name and take it.
  10. Offline


    I like the change too and feel its necessary to the future of Minecraft. Although it would've been a lot easier if UUIDs were used in the first place. At least future game devs can learn from this mistake
    Mayor_Mike likes this.
  11. Offline


    what happen if i want test my plugins with my offline server? :confused:
  12. Offline


    I think a lot of people are creating an excessive amount of drama over this, and I think some people seem to be thinking that everything has to be "ported" to UUIDs somehow. Am I wrong when I say that this change affects no other plugins than those that actually use player names as unique keys in persistent storage? What other possible use cases could this affect? And, for most plugins (ignoring migration/translation of schemas for a second), is it not simply a matter of changing those few lines of code that actually communicate with the DBMS to extract UUIDs instead of player names? I may be forgetting some extremely important and relevant aspect of general plugin development, but it just seems to me like a poor design would be the only reason why anyone would "have to rewrite everything" - in that case, this serves as a free lesson in software design, the hard way. Please correct me if I'm wrong.

    Pardon my sarcasm, but what an incredibly great way to alienate plugins that aren't affected by this change. Should I stick a badge on MobArena's front page saying "UUID Compatible", even though there never was an incompatibility to begin with? That seems a little deceitful to me. Absolute nonsense at best - it's like putting a sticker on a powerdrill that says "Potato Compatible". Without the badge, though, server owners (who are unaware of what's actually going on) will flood the forums, ticket system and IRC channel with "omg y u no uuid compat?"

    Perhaps plugin developers can make it clear on their project page that they aren't UUID compatible until they are. While a bit of an unrealistic dream (because who wants to openly state "my work sucks"?) I think it's a much, much more fair metric to work by, because the problem is that some plugins need to make the switch, not all.
  13. Offline


    Okay so if you have an offline server, your uuid is generated by creating the String "OfflinePlayer:<YourUsername>" and converts it to a UUID. This means that your UUID will always be the same in offline mod UNLESS you change your username. So offline servers will completely mess up if people change their name.
  14. Offline


    the only problem I'm seeing with this is the back compatabillity of older versions of minecraft as for signs I think it is possible by saving the UUID and the location data to a file or database and update the name everytime on the blockstate (when user is changed) but the UUID's in older versions of minecraft are actually the entity id's it concerns me alot since there are lots of pretty cool mods (not going to name them) which run in older versions.

    also I'm a bit worried by seeing Bukkit.getPlayer(UUID) and Bukkit.getOfflinePlayer(UUID) why not using a string on a offline player which iterates till it founds a matching UUID, maybe also with a caching method? because from reading the mojangs twitter its required to relog/restart to make the name change take effect which means you could make a perfect loop and update/bind the player name to the correct UUID when he joins, and when the player leaves you can still use the name as its not updated yet and the joining will update things acordingly, however I'm not sure if mojang will add nbt tags/json tags in the world files containing the UUID's that would be great, because you haven't to lookup/query things (which is in my opinion a no go because I believe not everything can be handled this way, such as when the lookup server is down).

    imo I think the name change feature is something I don't like, but complexity can be fun.
  15. Offline


    This will not effect offline servers at all then.

    Offline servers use there own DB that stores a name and a password. IF an offline player wants to switch account names right now, they will have to re-register on that server or have an admin switch the account.
  16. Offline


    It could affect Offline servers in some ways. If a plugin developer fetches UUID's from Mojang for their plugin they won't match those that are used by Offline servers. In that case there is a incongruity in data.

    Thus is life, you don't have to but your going to put up with all the questions if you don't. I added one to RocketTeleport explaining it does not affect it. It took 30 seconds of my time to do.

    That's a bit extreme. It's not stating "my works sucks" if that's the only option you had. Offline Players could not be managed with UUID in the past. Now they can. That's not the developers fault, but the developer does need to look at changing now that it is available. I have no problem putting that fact on my plugin page to let users know I'm aware of the issue.
  17. Offline


    From what I read, The UUID is made from the username when in offline mode, when the user say "bob" logs in each time he connects to the offline server his UUID will always be the same.
  18. Offline


    You are probably wrong :) - the number of use cases does not say too much about the impact of such a change. About any plugin that saves player-related data is affected. Permission plugins may seem "easy to fix up" code-wise, but in general all plugins that use interaction with offline players now have a problem in how to design the interface, not only core protection and economy plugins, but also add-on plugins. The usability and reliability of in-game interfaces is crucial, signs are facing death now, or welcome to the world of cryptic abbreviations and how to teach your players in an efficient way - good thing: signs tend to lag the client anyway. Bad thing: any interaction with offline players is affected, not just signs.

    Too much drama won't pay, many people probably won't change their names too soon, but still:
    - This is a breaking change that affects all past versions of Minecraft at a certain date.
    - User interfaces: Names become unreliable and UUIDs are not useful. Many user interfaces will have to be redone, even re-modeled completely, without having a widely accepted method to rely on, effectively resulting in less cross-plugin compatibility. This is what makes the change so big, and probably the actual lesson on software development.
    - Code becomes more complicated in general.
    - There are a couple of nice use cases for trolls now.

    For myself, i have a lot of ideas what to do to make it less hard for the players, e.g. a "i trust this very user" binding name to UUID, allowing things like direct money transfers using the name instead of bank account number, reliably arriving at the UUID and so on - problem being that it costs a lot of time, which could be used for improving other plugins. The other problem is that now tens if not hundreds of developers are each implementing their own version of how to get around those things, which i think is too many watts for the money :p.

    Edit: I forgot to mention the uncertainty about from which point on which UUID will be valid for a player and how long those stay valid - there is some users having multiple UUIDs (see Mojang ticket linked somewhere above) - so i am not too keen on investing countless hours to see that things just randomly changed at some point of time, and that i could have done without any effort (roll-over, delete maps, change to mini games etc.).
  19. Offline


    That assumes they are grabbing the UUID from the API. If they are fetching it from the web service, that becomes an issue. In my plugin I will be fetching it for the sake of migration because right now that's really the only way to do offline players, but offline servers will not match the UUID I have in my database then and players on those servers will lose the data they had.

    No he's right. It only affect player names and things associated with storing data with player names. A lot of people seem to think this is going to break every plugin out there. Mountains out of molehills. Your right though, those storing data with player names will have some re-engineering to do.

    UUID's have been around since at least 1.2. They just weren't synced with Mojang until now. So plugins that were using those methods won't break, they just won't have the same UUID in 1.7 as they did in 1.6 and earlier.

    I don't think they will need to be re-modeled completely. Not a whole great number of them anyway. In most cases UUID will be a drop in replacement as far as the interface goes. You can still look up a player by name and get their UUID once you find them. Granted, this assumes they are online. It's not perfect in all cases, if your command allows offline player names to be used, it's a bit harder. But again, mountains out of molehills.

    No, it doesn't. That's just completely wrong. In most cases it's exactly the same with a different object type.

    Not trolls, teachers. We are trying to help people understand this change which is coming whether we like it or not. Fear mongering and complaints about it isn't changing that, and not really helping.

    I mentioned it earlier but that was 50 players out of 3.1 million, and Mojang was fixing it (it's probably already fixed by now).

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


    I see your point and this is indeed a confusing issue to work on.

    After giving it some though I think I can see the how this should play out (my own opinion). If the plugin is still fetching the UUID from the web server when the server is in offline mode, this would then be counted as a bug. There will be the issue of offline UUID's and online UUID's not matching but this is the point of offline mode, you don't connect Mojangs authentication system.

    If a plugin mast stay connect to Mojangs authentication system while in offline mode, I guess the plugin would have a good reason too.
  21. Offline


    Agreed, in most cases it will be a one time migration though. You won't be ALWAYS connected to Mojangs system, just long enough to convert player names in your database to UUID. I will probably end up making a check to see if the server is online or not, but the problem then how do you get a UUID for a offline player in offline mode. You said they were derived from the name, there may be a way to calculate that yourself.
  22. Offline


    He was not right in assuming that it is "only" a small thing in general. Usually those plugins pose the very core aspects of many servers, probably including most of the big ones - things that are attached to players and things that players attach to. I stated about the interface question already - trying to not understand the impact of the change does not help understanding the impact of the change, after all.

    Well there could be a slight lack of reliable statements on how/what/how-long with the UUIDs.

    Using UUIDs for in-game interfaces is totally out of the questions, have you ever designed a user-interface? Of course offline players are just as important to a huge amount of servers (e.g. for economy+shops), and even online players can be different players than the last day (won't be in most cases, but could be).

    It's more complicated, also because of having to interface to one or even potentially many user-interface helper APIs. Checking equality on a UUID instead of a player name may or may not mean more CPU usage, but that's not the point.

    I am not having this discussion in mind, but trolls i mean: there is now a couple of very nice use cases for actual trolls, e.g. choosing a similar nick name to some "important person on the server" for no charge at all, in order to confuse people.

    It was stated to be "found ~ 50", whatever that means. I will not rely on "probably fixed". There are implications with this, at least you will have to run checks if players have multiple UUIDs, if you take the change seriously.

    UUIDs are not nice for handling them internally - it's boiler plate stuff both for code and cpu, especially if you take user interfaces into account - nice for changing names without need for a central name server on Mojang side, nice for changing an account name without ever having to type it again, but otherwise not an advantage, on the contrary it does have negative side effects, some of which may change the landscape of Minecraft a lot (e.g. less signs). Not that i am condemning this change, but it's clearly not just that much nice to have.

    Don't calculate them yourself. I think Mojang has an API service for looking up the uuid for a name, referenced here:

    Edit: Never mind, i am not sure what scenario you have in mind for calculating them (offline mode server!?), also if that service will be online always.

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



    I don't worry about the few plugins I'm using.

    I'm worry about the whitelist that I manage manually, with a text editor.
    I only use the built in whitelist funktion in bukkit. There are only a few users on the server so the "need" for a plugin, to handle the whitelist, has never occurred.
  24. Offline


    asofold That article is referring to online modes. And the tilde "~" means approximately. So it may have been 53. Still out of ~3.1 million.

    I'm not saying there aren't going to be some plugins that do have to re-engineer things. But it's not the world ending change that people seem to think it is, and most plugins will easily migrate or don't need to.
  25. Offline


    its not going to be to bad for Developers i am sure a plugin like Mcore will have uuids setup soon then other devs can just use mcore to rectify there code like mcore.get.uuid=autoupdate-username blahblahblah :p There will be a plugin that other plugins will rely on to find out the users uuid is what i am saying :p
  26. Offline


    Most plugins can manage to make this switch without making a difference to end-users. Things like a whitelist are difficult to manage, because people do a lot of manual editing... but we're working on a way. Like I mentioned, before, by the time it becomes relevant, you shouldn't have to worry about much.

    No developer wants to be left behind, and this situation could easily cause that. We're all working hard to make sure it doesn't happen, which makes the average user who wants to just get a plugin and use it not have to worry about much.
  27. Offline


    Even with "just 50", one has to prepare in some way (serious people check all players for multiples, very serious people keep checking until Mojang announces something related, not that much serious people just remember it for the case of trouble). There are still a couple of maybes, which can lead to much trouble with using not-actually unique ids or not-in-time-unique uuids. Could be this will be washed away with a statement by some Mojang employee - i'd be happy, even if the statement is months old and can be linked to, just i need something to rely on, not "maybe you can migrate it all at some point of time in the future, though no one knows what current uuids will be next week" :p.

    You might be underestimating a couple of things:
    - Some plugins are virtually everywhere, certainly all those plugins that store data about players, but also plugins that allow referencing offline players.
    - Some is not too few, likely the Bukkit servers with at least one of those some plugins will sum up to a high percentage of total players, probably 70%+.
    - "easily migrate": Creating a working in-game interface is not too simple without relying on player names, also regarding cross-plugin compatibility can be a problem. Concepts to deal with the uncertainty of names are not just popping out of thin air for free.
    - Agreed that it's not ending the world.

    I bet most servers don't use that plugin - i suspect that there will rather be one way to deal with the change per developer - ending up with a multitude of API/suggestion plugins, in any case with an increase of cross-plugin dependencies, which then could lead to a partitioning of the plugin landscape, because you will have groups of plugins forming around their favorite helper-API - problems are not so much to retrieve a uuid or a name, but to provide a user-experience worth mentioning rather than forgetting about, that is to say: acceptable ways to reference players on signs or with commands.
  28. Offline


    Are you saying that my whitelist will be updated automagically when time comes?

    Allow me to doubt that. At the minimum I have to update Bukkit. And I believe that the UUID:s have to be added to my whitelist, either manually or through running some sort of "update tool".
    Remember that until today have I handled my whitelist file manually.

    So... My question remains:
    When and how do I add the UUID:s to my Whitelist file?
    JaguarJo likes this.
  29. Offline


    The whitelist is Minecraft, not Bukkit. You will have to update Bukkit to get the latest implementation of Minecraft but Minecraft's code will update it. That is why EvilSeph said:

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

    So the answer to your question is, you don't. Mojang will convert your whitelist when it is needed.
  30. Offline



    What I meant, was that by the time MC1.8 is released, and player name changes implemented, plugin developers will have made their plugins compatible with that change.

    I didn't think I needed to explain that you would have to download these updates, in order to get the update.
  31. Offline


    Thanks for that clarification. Although, due to the time it usually takes to update bukkit (No. That's not a criticism. Keep up the good work.) that will leave a security hole for the period that we wait for the Bukkit update.

    What part of the word m a n u a l l y is it that you don't understand?
Thread Status:
Not open for further replies.

Share This Page