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


    Not sure why there are questions being asked that are already addressed in the OP.

    When Will This Update Be Coming Out?:
    Well, the update from Bukkit to address UUID's is already out. It's been out for a while, now - since around Mojang implemented UUIDs for accounts.

    As far as usernames being changeable, and therefore no longer being a reliable way to identify players, do to the fact that usernames will not longer be, necessarily, always assigned to the same player, Mojang has only stated it will become an available feature around the time 1.8 is released.

    Will Usernames Be Unique:
    Yes. Kind of.

    The concern is mostly for plugins that use player names as a way to assign data to a player.
    Whitelisting plugins, for instance, work by whitelisting a player name.

    However, if EvilSeph changes his username, el3tehax0r is free to change his name to EvilSeph. Meaning, where EvilSeph was previously whitelisted, so will el3tehaxor be, as his username is, now, EvilSeph.

    As well as any other plugin that uses the player name to consistently assign data to players. Economies, for instance. If you change your name, you'd lose all of your information from before, because you would no longer have the username that the information was stored to.

    But no, there will never be two players with the same username. They're unique, in that sense.

    Blah1 General GummiBearz
  3. I hope these are addressed before allowing to change the player name:
    - UUIDs are assigned and from then on stay "forever".
    - Mojang adds some service/functionality to look up the UUID for a (legacy) player name, for data-conversion.

    We can't prematurely switch to UUIDs, unless we know those will stay (rather forever). "Look up in a database" is also in danger of making cross plugin compatibility more difficult. Will there be a server-based database/mapping support for "name or id on this server" or will we have endless amounts of API-plugins? I hope Mojang is still planning with plugins (no joke :p), otherwise we might get a horrible multitude for "name on this server (~auth)" plugins. It is just impractical to have names changing all the time, unless maybe for minigames - also the abuse potential with "i am brian" is there, good times for trolls, more work for maintaining a server. This might radically change things.

    For me much will depend on durable statements on UUID assignment-done+lifetime+future-policies and on how the transition phase works out in particular.
  4. Offline


    FerusGrim A whitelisting plugin would not work with Bukkit API that uses 1.8 MC since whitelisting works by UUID and the parameter will be (hopefully) UUID.

    Even if String as parameter is used the whitelisting simply would not work as a username cant be used for whitelisting at that point. The whitelist plugin would simply stop working.

    Everthing else that uses its own database like permission plugins or inventory plugins will have to switch to UUID soon in order to work after 1.8 release or those plugins could open a security hole IF someone decides to switch to another username.

    Hopefully not enough script kiddies have too much time at this point.

    One possible attack vector would require knowledge about the server like knowing when a user with extended rights will change its name.

    To grief a permission protected server he would need to know when a user changes its name.

    Using current known methods this can be done via constantly monitoring certain players and attack directly after he changes name.

    BUT this is based on an assumption that there will be no limits. I simply can't believe that they will not implement protection against such attacks otherwise we are in need of a plugin that can migrate one account to another by using a secret key for example ...

    Anyways i see less potential in using such method since only old servers using such plugins may be affected. If Popular Plugin Developers will keep up with this roadmap there should be no problem.

    Edit: A good starting point can be found here:
  5. I think this already exists, so one thing less to worry about. But then lifetime and future-policies...
  6. Offline


    Wait, what? A whitelisting plugin wouldn't work because it uses UUID? But the parameter will hopefully be UUID? I don't really understand what you mean here.

    I maintain a fairly popular whitelisting plugin, and I'm currently working on migrating it to use UUID, and, so far, I haven't run into any issues. My post above was explaining to people why this change was necessary, listing off a potential danger as someone's username being hijacked and affecting a whitelisting plugin which hasn't been updated to use UUIDs (thus, why the change is necessary).

    Again, what? Why would it stop working? Code would still be valid, it just wouldn't be SAFE, anymore. The methods of extracting and denying or allowing access to features can still be marked against a username. The deprecating that the function is going through right now is temporary (a form of PSA, if you will), and will be removed when 1.8 is released, as the method is still valid and safe in many formats (such as chat plugins).

    This is true, but contradictory to what you said above. Why would these plugins work anymore than a whitelisting plugin, after the 1.8 release? Yes, they would be insecure (and a really sloppy way of tracking characters, at this point), but valid. Just like anything else that tracked player data by their username.

    That's what I was saying in my previous post. This is irrelevant in plugins that track player data via UUID, thus why every plugin developer who tracks player data should be changing.

    I think you misread my post, a bit.

  7. Offline


    Pogo made a video explaining this quite well, if anyone finds trouble implementing this into your plugins.
  8. Offline


    FerusGrim i see why this is confusing. Seems i was assuming too much. I was thinking that a whitelist plugin would use Bukkit API since the server already supports it. I was not thinking about other whitelisting plugins who might just have their own implementation and kick a user based on an internal database.

    If this is the case then they have the same problem like any other plugin using player names for identification.

    Note to myself: I also should add a line that clearly states "this is not only a message to you" next time since it seems that its not obvious where a comment starts and stops...
  9. Offline


    I don't think so because you can't use color tags in your minecraft name!
  10. Offline



    There are a lot of plugin developers in this thread. :)

    As a (non developing) server owner I like to knew when and how I add or replace those UUID in my current whitelist?
  11. Offline


    Whitelist plugins would have to update this - it's not something you, specifically, need to do yourself. Currently, there aren't any Whitelist plugins that I know of that are updated with this method.

    I'm working on updating my whitelist plugin right now. Feel free to look me up on BukkitDev under the same name I use on the forums. Unfortunately, I don't think I'm allowed to link directly to my plugin or my account on the forums.

    The whitelist plugin DOES use the Bukkit API. Not sure what I said made you think it didn't. o.o;;

    The code:
    will still be valid before and after the 1.8 update. I'm not sure why you think that a whitelisting plugin would suddenly fail after the update. It should work fine.
  12. Offline


    .-. This is such a stupid thing that will be added. Usernames are like the identity :'( Now people can just copy other names
  13. Offline


    You can start by identifying any plugins you use that reference a player by their player name. Then keep a close eye on updates for these plugins from the plugin developers to ensure they will work with UUIDs.

    Perhaps plugin developers can make it clear on their BukkitDev project page that they are UUID compatible to help us server admins who are concerned about the upcoming changes?

    That said, I will re-iterate @EvilSeph's point:
    Emphasis mine.
  14. Offline


    Yeah but you cant anymore use getOfflinePlayer(String name) and need use getOfflinePlayer(UUID id)
  15. Offline


    Hhmmm I think Bukkit will create new options for that and btw I think you can still use the old playernames for the scoreboard?
  16. Offline


    For people who aren't developers - you won't notice much of a shift. This is NOT that difficult of a solution to solve.

    For plugin developers - There is an easy way to keep storing data under the UUID, while having an accurate username (even if that username gets changed).

    Simply store data under the UUIDs, like you normally would have a username. You can store the username, as well.

    If you decide to store the username, just have a simple check (forgive my lack of IDE, here).
    1. Player player = event.getPlayer();
    2. String stored_username = plugin.getConfig().getString(player.getUniqueId().toString().replace("-","") + ".username");
    3. if(!(stored_username.matches(player.getName()))){
    4. plugin.getConfig().set(player.getUniqueId().toString().replace("-","") + ".username", player.getName());
    5. }

    EDIT: I cheated and corrected the code in my IDE. >:)
  17. Offline


    I'm quite interested, will this actually ''break'' cracked servers since most plugins will be written to convert/use the UUID's whilst I assume cracked servers will not be using the UUID's since they skip Mojang's servers anyway?
  18. Offline


    I believe I read that Offline Servers will, instead, generate an MD5 hash based on the username of the player connecting. So, in theory, plugins should work fine.

    However, there's no way to manage safety with an Offline Server, anymore, as usernames, at that point, are interchangeable. But, for Offline Servers, they always have been. So I suppose it doesn't matter.
  19. Offline


    I am not a bukkit server owner who depends on other people's plugins. But what if those plugins do not get updated?
    Players can change their names to higher ranked players or players who have claimed land or a chest. Isn't it going to break a lot of servers?
  20. It will certainly break a couple of plugins that use signs. Not sure recovery is possible or even makes sense, what to replace old player names with? The UUID is not an option, and a replacement system probably will be "the server owners choice". Edit: having multiple replacement systems at once probably won't be fun, so "the server owners choice" for some will just be to drop some plugins or even the map.

    I won't drop a map back from beta, at least not without dropping Minecraft, so probably i'll just write a plugin that saves pairs of UUID+name and prevents players from joining for whom either does not match, at least for the transition phase, thus players who change their names will bite the dust for a little bit.

    The big problem for me is the question, if the current UUIDs are final or might get changed with coming releases. I am too lazy to search for a statement by Mojang/sters on this, so i hope some link gets dropped in on the UUID-validity+lifetime+future-policy question.
  21. Offline


    I'm curious why UUIDFetcher is recommended over AccountClient?
  22. Offline


    This isn't a April fools day joke is it? Can someone PLEASE explain why Mojang is allowing people to change their usernames? It's such a security hole.
  23. Offline


    <----That sounds like a good idea. I've updated my top 3.

    They announced it months ago. So, if April Fools in January, maybe but, probably not. It's not a security hole as long as you don't use player name based plugins.

    That's 50 users out of 3 million.
  24. Most interaction with players is done name-based, be it commands or plugins storing data, it should be hard to find plugins that use something else instead of player names and at the same time do something useful. Correct me if i am mistaken...
  25. Offline



    I wasn't one of those people who asked such a question about UUIDs. My question (and this is for anyone to answer) is why Mojang decided to use UUIDs instead of the old method of storing names. I know that they've decided for this change a few months back, but why couldn't they use an alternative like making "account names" (which are basically UUIDs, but in string format) and a changeable "ingame name" or "screen-name"? And perhaps have a switchable option, ingame, to view people's actual account names or screen names.

    I don't know any code, but I've a few outdated plugins that rely on storing player names, so I'm guessing that I should start learning now, and fast. (I'm also aware that dropping plugins can be used as a temporary workaround.)
  26. Offline


    Your mistaken. Plugins use player names in commands mostly when the player is online. If plugins update to use UUID, they will grab the UUID while the player is online most of the time. A player (probably) won't be able to change their name while on a server. It probably won't take effect until they log off an back on again. So, that means when a command is issued that uses a string based name, it can be easily converted to a UUID by searching your online players.

    Keep in mind, Mojang has said they will allow players to change their name, they did not say they would be able to use non-unique names. While the details still aren't certain, most likely you can't use the same name as someone else.

    That said, there are a few reasons to use player names in commands when a player is not online. In those cases they will have to fetch the UUID.... until Minecraft updates player files, as EvilSeph said they will be moving the file system on your server to be stored by UUID, all those files with player names (which is how getOfflinePlayer(String) get's players) will contain the information you want already offline.

    Here is a tutorial I wrote that directly compares player name usage to UUID usage. It doesn't have the offline fetching, but other than that, you can do everything you could before.
  27. Offline


    Sorry for mis-tahg'ing you, then.
    Personally, I like the UUID change, more than your proposed idea. I support either way would work, but from a programming stand-point, UUIDs would be simpler. The changes we have to make would be fairly similar for each idea, but UUIDs being so different that just another display name makes the challenge a bit less daunting, as there's less chance of confusing the two.
    As far as your outdated plugins are concerned, you can always request them. :) The request section is fairly active.
  28. Offline


    UUID's are an object, not a String even though they can be represented as a string. This makes it much easier on developers. In the past we had to use .toLowerCase() everywhere, miss one place and it's a bug. But even converting UUID.fromString(), we don't care how it's cased because the object handles it for us. I like UUID personally. I think people believe this is a bigger issue than it is. Reminds me of the good ol' Y2K.
  29. If plugins update :). All past versions of CB/MC will need plugins that update. Auth plugins don't work well here, because they don't help the seldomly joining players, or those that took a break. Without a tool to fetch all known players uuids server owners will not be able to continue legacy servers. It's a fancy feature for the player to be able to change the name, but now servers have to use special tokens on signs and some commands instead of the actual names. Likely there will not be a built-in server-id system for short tokens/ids just for the server, so different plugins will have different approaches - not a good thing in the first place.

    Some of the uncertainties would be show-stoppers. Mojang has to make the uuid stuff rock solid and lasting, or they can name it Mini(Game)Craft in the future.

    I will for my own server write a thing that builds a database of all known names, uuids, timestamps etc. to be able to track back stuff, updating with players joining. From some point on, until it is all migrated, i will not allow players with changed names join. Then... sign based referencing of players will use short tokens/numbers, in addition i might allow "still unchanged" names to be used, where i can provide it, otherwise add summaries about names and their tokens (history of names). Edit: (skip the details :p)
  30. Offline


    Looking forward to seeing the creative solutions to handling this big change that people come up with over the coming months!
Thread Status:
Not open for further replies.

Share This Page