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. Virtually any thing can be done in software, but usually at some cost... time, depending on more plugins, being less interoperable with other plugins at least for a while, dropping backwards compatibility, dropping features, decreasing usability, too much cost - differing effects/severity to be expected.
    Converting all of that to uuid means inventing stuff that makes it usable from the command/sign side. Think about the user interfaces to reference offline players.

    Let's focus on problems then, if there are no attacks :). The op list is not the best example, because it is a critical admin/owner-only feature, that makes it rather acceptable to actually type a UUID, based on whatever verification method, if the players are offline.
    However a plethora of cases with "ordinary" players having to reference offline players can involve risks, depending on how things are done by plugins. I'll try not to re-hash too much, so here just the plain text: (Why don't they have a wrap-text option, why does render creole not at all work?)

    The slight logical problem is to remove something from an offline player when a player with the offline players name joins, for the case of referencing by name, because the reference is the name for the user interfaces in question. Not using the name would force us to reinventing more cross-plugin-compatibility-wheels. All doable but it's not just the chicken run, like some are suggesting.

    I will write my own as hinted at in several posts, because i want more data than most might want, not sure i'll publish it, though.

    That's a misjudgment in my opinion, see above and posts above.
  3. Offline


    If a player.getLastKnownUsername() like method gets implemented then all of my headaches are gone. As for the people who develop plugins that input names onto signs etc.... I feel your pain.
  4. Offline


    They could have another one for just UUID and have a get current username....
  5. Now I feel like making a plugin that stores the UUID and a list of names used by that player from newest to oldest. That will help lookups in plugin configs much easier. Possibly adding an API for other users to use the list to their advantage. Idk quiet yet though about the API.

    That's why you make a plugin that also stores the current or last seen username of the UUID owner.

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


    That's the whole point. Almost anything can be done with this system that could be done with the old one with only a very few exceptions. Mojang is not going to withhold their most requested feature (their words) because it inconveniences you or any other plugin developer.

    All of those risks are either incorrect assumptions for reasons I've already explained or they are justified by bad coding practices or require a previous incorrect assumption to be correct. You obviously don't understand this implementation.

    Why is monitoring a player join event and removing a piece of information from a database such a problem for you?
  7. Offline


    I slightly think most of you guys are overreacting. It's a few refactors and a converter, then your plugin is updated. Tools have been released if you need help with the UUID process.
  8. Let's start counting how many developers are going to write a similar plugin :).

    I am not claiming they should not do this, it's not the point of what i am writing here.

    Please be more specific! I made some easy to catch 0nes on purpose, which may seem slack, but you must see that there are servers with 20, 30, 40, 50, 60 plugins - many servers - then think again. You either don't read right (3rd, 4th time responding like this) or you don't understand yourself, or you are too lazy to really dig into it. I am doing a little bit of "opposition by default"-thing here, but it's obvious that some people are underestimating the impact.

    Don't over-simplify - i am more than capable of doing things like this.
    You could be more specific as to why this removes any problems, because a database is not the solution to not knowing the uuid of a yet offline player, neither does it prevent you from referencing a player that is not intended to be referenced.

    Apart from actual reasoning, this makes plugins more complex, more error prone, and less performing, thinking of multiple plugins doing this with their own database tables.

    You also do not say anything about the user interface question.

    Note that i am not trying to propose the absolute killer-argument, but you won't be able to clean the table with that ways of "argumentation".

    Sounds simple and certainly is correct for "silly hats" plugins!
  9. Offline


    asofold That is the precise reason I write all the plugins that interact with players myself :U

    With how I'm using lastKnownNames, if the lookup ever encounters 2 results (while looping over the names list) it does an asynchronous update to the UUID->name table using provided UUIDs and re-launches the method, notifying the player that Player X's name has changed, but the operation was succesfull/failed depending on what it did.

    I really don't see problems with this - updates are only made when needed, meaning that logged out players will still be accessible by their own handles unless someone new shows up, in which case the old name gets popped into a name history list and overwritten with his new handle, and back-end every lookup is made by the UUID.
  10. "when needed" - how do you actually solve the problems with referencing the wrong players, if using names in interfaces, addressing players who changed their name "away" and/or "to" the used name?

    Edit: Note, that the problems arise already when the players changing names are still offline. Also denying all interaction once the new one joined won't really be an option.

    As far as i can see, one can only solve this with querying the UUID for offline players at the Mojang servers, given a name. The other big point is the trust-question - your players probably get used to using the history thing for checking, but probably it's also asked too much to each time check if oyur buddy is your buddy - that's why i will introduce a trust/buddy system for my server which allows marking people (uuids) as trusted, so they always get feedback quickly and some critical commands won't execute if the referenced player is not the "known one". That means i need to recode a lot more stuff, also interoperability will suffer, or i will fork/reimplement more plugins...
  11. Offline


    We already had problems with people using nicknames to impersonate other players - Intentionally tricking players to let them TP into the other players' bases. This username thing could be 10 times worse.
  12. Offline


    Bobcat00 Well you can't change nickname to a used nickname. So you could I guess accidently tp if the person has a similar name, but can't be the same.
  13. Offline


    But there is no problem here. If they haven't logged on, your still using the old name and the old name still points to the right UUID. You can still use that old name because the name is still correct as far as you and your server knows, and the UUID it points to will not change. When they log in, the new name is retrieved and matched to the same UUID, from that point on you use the new name.

    By the way, do not retrieve a players UUID (or any Bukkit API) asynchronously. That was the main problem with your "risks", the very first one was based on bad programming and most of the rest were dependent on the first one being true.

    Your making mountains out of molehills.

    But nicknames weren't backed by anything consistent. If only they had something consistent in the background, like a string of 32 hexadecimal digits that would be unique to each player preventing unexpected changes. Someone should invent something like that.
  14. Offline


    No, we had multiple players with the exact same nicknames (even color!), set with the Essentials /nick command.
  15. Offline


    Bobcat00 Yes you can cheat displayname, but the username is the same. If your teleport command uses the displayname then you can have issues. The minecraft update will allow to change "username". Doesn't affect nicknames, that issue is with the plugins.

    Edit: in the code there is player.getName(), player.getdisplayname() and now player.getUniqueId(). The first one will be changeable from the mojang website, the 2nd one is changeable by plugins and the last one can't be changed.
  16. Offline


    This will effectively be hell for most servers and plugin devs.... UUID's are better, but they will throw a real curveball for plugins and servers, and it'll hit at the core. Such a transition is kind of stupid if you ask me... Mojang MUST know how much of a threat this will be, yet they continue on...
  17. Offline


    Coincidentally, when 'all hell breaks loose' and the majority of server owners cant understand how to make this transition and give up, or new ones find it too daunting, and existing servers go through challanges and beyond to persist their data from one plugin to the form needed for another plugin to survive, as some old reliable plugins that have gone unattended for ages but busily work away until the coming days... Mojang has their couple-clicks-and-all-done server setup, complete with one-button click switch-server-into-a-minigame-map-and-back settings, spreading country to country to country, with Realms available everywhere but North Korea and Antarctica the day before they throw the switch on 1.8 client. They might even capitalize on the "Aww, your favorite server went boom?" and "All those confusing plugins that dont know if they're going to keep working or not are breaking the reliablity of your server?" -- "well then, why not do a couple of clicks and host your server with us, sure its not loaded with plugins like you're used to but with all the new commands we've jam packed into 1.8 minecraft, you wont feel like you need them. Not only that, but for merely a couple clicks and a few minutes, you can be up and running today, in control of your own 1.8 server, in just a few minutes. Just think of it - all those people out there who have upgraded clients and refuse to downgrade because the world should revolve around their desires - now it does! Take advantage of that, be there for them, build it and they will come. Impatience isn't a problem anymore(TM)"
    They're not going to throw away an income stream of half a million dollars spent just to get a new name, without believing there is a million dollar stream to fill the vacuum. Realms will be fully charged up and ready to begin the onslaught of saturation 'marketing' within hours of 1.8 release. No coincidence that the most aggressive infrastructure change that will be a dinosaur-erasing impact strike requiring smart, attentive adaptation to make it through the confusion and fallout happens to have a convergent project timeline with 'world domination of server hosting accessability'. And becasue of the short memories of many server folks, they only remember the last time a big server upgrade was done, and it took over a month. The fact that its been a whole few days now with no server starts to make them feel queasy, unsettled, and they are having flashbacks and convincing themselves that if its not there in 3 days, then likely, it wont be there for a month, and they've been told before 1.7.6 wasn't even a big change (its still 1.7 something) So they are starting to panic now, anticipating another month, not realizing the uniqueness of the 1.7 conditions. And knowing that they'll have to go through all this again in a short time... I think huge masses will say 'ah, letme try it for a month, after all, wont be a bukkit for that long' and be off and running to Realms for their taste of that heavily-pushed drug, and a lot will be hooked.
    Not the majority of serious server folks of course, but the 99%ers who dont last a month in the first place.
    An environment of fear will be the viral marketing drive, and simplicity /promise of no complicated files to edit, just click click click and done.. that will be plenty to make up for the potential losses of full-priced 'changed names' current system.
    Mojang must know how much of a threat this will be? Sure they do, its the inevitable asteroid that is going to make a dent, knowing that a lot will not make it, and the backlash that will follow against them will sting But there is money to be made from doomsday prophesy right up until it happens, and when it does, its going to shake things hard, but the strong will survive and new ones will adapt to the environment. Mojang just happens to be stockpiling everything and readying survival gear with the advantage that they will control the exact moment of touchdown and will be able to shape and mould the environment of fear and confusion into a tangible benefit.
    Was that the plan all along? Doubtful - name changing systems and server hosting were two always desirable objectives, but somewhere along the way, I bet project timelines started to show convergance and it became clear that they can turn the dramatic one into a massive benefit for the other.
  18. I can't prevent people from not reading what i am writing here, but of course i can try to be more concise and short.

    With the local database approach, the the old player A is referenced after name changing. However that might not be wanted by all, as i have shown clearly in the 3-players example with the name changers A and B staying offline, because a third player C could log in and wants to reference his friend B who changed the name to that of A ("i'll be on today"), but the commands/signs still reference the old player A, whom the third player does not know at all, due to using a local database approach.

    If the new player B who changed the name to that of the old player A joins for just a second, the confusion potential will be big. Without a buddy system to warn people or even prevent commands, the new player B would get all the "money" instead of the old player A, concerning services that use names, unless players are able and willing to check what they are doing. Alternatives to not use names have been covered by some posts of mine above in a pretty sufficient way, i'd say.

    Just relying on a local database without further safety nets is not acceptable for many server owners, neither for all plugin developers. A trust-framework as i described in earlier posts may be a thinkable approach to complement your suggestion, but at the cost of being complicated to implement, killing off cross plugin compatibility, even adding the need to use that framework in many if not all name-based interaction on your server.

    Even if you wrote a FAQ about how to change your name, and about joining all servers quickly, it wouldn't quite undo the trouble, be prepared!

    Asynchronous lookups can be necessary, if you want to provide a certain mixture of usability and consistency.

    I wrote that some of those risks are easy to undo either way, but they are meant to cover ground, some apply in virtually any thinkable case, so your statement is not backed up sufficiently to rule out my arguments, also consider reading the first paragraph of this very post!

    The risks are numbered for referencing, i gave enough reasoning to check them out, otherwise you will likely go trial-and-error on a couple of those - "you" also seen as some server owner.

    It's more like: if you check out the mist on the molehills, you will encounter clouds in the distance - if you check out the clouds, you will eventually come to recognize some mountains. Not stating that have to go for the mountains, but you can't really keep dry feet on a molehill, when the flood comes, unless you find that an acceptable risk.

    I can only repeat that this is not as simple as some people like to see it. There may be differing opinions on what an acceptable risk is, but basically the simple proposals in this thread are either insufficient for preventing inconsistencies, or they are just not acceptable for many. I can only recommend to start building the safety nets, dig into it, see what can be done and what can not be done, it'll be more clear then what you want and what you don't want.

    Some servers do complete restarts now and then anyway, so this would be an opportunity :p - but mine doesn't, so in order to actually implement something, i will reduce my attention for this discussion by a good bit from now on :).
  19. Offline


    Forgive me for asking, but will the namechanges be completely universal do you think? I mean, will this affect all versions of Minecraft or will this be something that will be "enabled" on servers running 1.8 or above? This sure will mess up a ton of servers that run very early versions of Minecraft, at least if they use plugins that heavily rely on names (as most of them do).


    Also, how will this affect the player.dat-files? All progress should be lost if you change your name, or are the .dat-files already UUID-linked?
  20. Offline


    Likely it will affect all versions. .dat files will automatically be converted by Mojang themselves.
  21. Offline


  22. Offline


    omg two weeks without internet and this happened???? *in shock*
    MarkehMe and xize like this.
  23. Offline


    It's the end of life as we know it.
  24. Offline


    I see all of these UUID API's. Is using <player>.getUUID(); really that inefficient, or could it be used for plugins?
  25. Offline



    it depends, I can say sort off, if you ment with p.getUniqueId(), the problem is in older versions of bukkit p.getUniqueId() is for entity id's rather than the UUID from the mojang account it self which means compatability problems thats why p.getUniqueId() could be inefficient.

    also for bulk migrate users, for example if they have not played longer than 4 months and changed their name and before they join this could be a reason to.
  26. Offline



    So would p.getUniqueId() not work at all to repair plugins that are affected by this?
  27. Offline



    it would certainly work, but there are 2 scanarios where it wouldn't.

    older server versions actually require their own UUID fetcher as p.getUniqueId() is the entity id in the world, but in the latest up to date bukkit versions these are the mojang uuids, but some developers urgely want to make it compat with every version of minecraft, some devs not so I can't say its completely not working, or inefficient but more where the developer is aiming to at this point.

    another scenario is the migration from databases or flatfiles based on player names to uuids:
    the problem is when the name change features come alive, and a player or even a admin/moderator changes his name before he actually joins the server.
    there is no way to update his name to the correct file, or database entry or to remember his UUID, in this case p.getUniqueId() feels bad in this scenario but in place of that you could use a api to fetch all data all at once to UUID's so this scenario could never happen.

    my conclusion is its not bad or inefficient, but more likely as incompatible with older versions/and problems with migrating retired players, but for a later stage its perfectly fine.
  28. Offline


    I have a question. What if instead of oping players, you op that players uuid.

    Let's say a Server owner oped someone named OpGuy. While he types /op OpGuy it actually ops the uuid (so in order to be op you must match this uuid - which is something you can't change). So now let's say this player changed there name to ThatKoolGuy, then another player made there name OpGuy. They won't have commands because the uuid do not match but the op ThatKoolGuy does. I am not sure if this would work. Maybe as a temporary fix?
  29. Some plugins can convert to UUID use instead or alongside with player names. For other plugins that would be not not enough, for some it also depends on what kind of consistency and protection against abuse and confusion server owners and/or plugin developers want to provide.
  30. Offline



    But lets just say that my plugin would only be used on the newest builds of Bukkit, and has a completely new database, there would be no problems?
Thread Status:
Not open for further replies.

Share This Page