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

    garbagemule

    Relicum
    I get the feeling you haven't really read through this thread (understandable at 11 pages, though). I was merely pointing out that there is "more to it" than just using names when you need to display a name, and UUIDs at all other times. I'm trying to help clarify the actual challenges for affected developers, and I have already provided ideas for solutions more thorough than "update your records". As mentioned in a previous post, the greatest challenge is allowing users to reference offline players by name (plugins don't need to, but people do), because without recording a "last nickname" for players who have visited your server, you can't be sure you're referencing the right player when you type in their name, which is always the case for players that haven't visited your server yet. Again, just providing some perspective, pointing out something that appeared to have been overlooked.
     
  3. Offline

    Necrodoom

    Relicum how do you know a user cannot change his name while on the server?
     
  4. Offline

    xize

    Necrodoom

    ive seen Dinnerbone made a tweet about it, but it is very old and I cannot find it anymore however that would not garentue it will always be working like that, but on the other hand it would make logically sense if they hold it that way though for the sake of sessions, since the sessions are able to let a player disconnect now since some time around the uuids.
     
  5. Offline

    ZanderMan9

    Relicum I understand completely the concept. Every genuine (non-cracked) account has a UUID. That UUID never changes. Usernames, however, do. Now when using a command on an offline player, do you want to type out a UUID? I think not. Here's the scenario I'm looking at fixing:
    Player A has username ZeldaLover3345.
    Player B wants to steal that username, so waits for player A to change it.
    Player A changes to ZeldaH8r, and player B changes to A's original name.
    Now, before B left the server and the whole name-changing scenario happened, he griefed. Moderators aren't aware that the name change has happened, and so simply enter the username of player B, which with my idea is still linked with B's UUID.

    (But, when they both try to join, the database is updated to the latest info)

    I didn't explain it very well the first time, I hope this clears it up.

    EDIT: Also, I'm a developer myself. I'm no expert dev, but I'd rate myself as somewhere near beginner-intermediate. Now I know you must be used to people with no concept of programming and even it's meaning asking nonsensical questions on the Dev Help forum, but I bothered to actually learn Java before jumping into the Bukkit API.
    And neither am I an expert DB person, but that doesn't mean I can't look at the situation and apply my knowledge to it. Just like a math teacher could teach a history class, albeit not as well.

    The way I see it, we have two options:
    1. Everytime a username is entered, look into Mojang's user database (slower most likely, and problems can occur if a moderator remembers a user by a different name than what they currently have)
    2. Rely on our own DB's, however we want to set them up.

    And I know my idea is by no means perfect and has many flaws, but I have yet to see an idea that actually fixes the issue of a person being incapable of remembering people by UUID. And I'm not username-obsessed, I just know that server administrators need to be able to perform commands using a username, not a UUID. The issue comes in when that needs to be processed. We need to have a smart system that will convert usernames (what people will be facing with), and UUID's (what code will be facing with).
     
  6. Offline

    asofold

    Proper user interfacing with name changing is nowhere near simple.

    Maybe plugins will start relying on the local "last-played" cache, but whatever "most" plugins do, there will be server owners and developers who don't want that, thus will have a hard time integrating everything, in addition to the question how to give your players a reliable way to know their "friends". Some plugins only migrate online players - also painful, thugh understandable.

    I assume "theft" is not meant in the ordinary sense, but like changing to a user name that has been abandoned by someone else. Against such a database with at least UUID + name is very useful - until i have fully migrated user interfacing and all, i will rely on such a database of "original name owners", in order to lock out players who change to a name that had been occupied before.
     
  7. Offline

    codename_B

    The logging program would log the grief under the UUID of the second player, even if the username was the same admins would be able to compare the UUID versus the original name and see that it is different. That's why having UUID compatible plugins is a good thing!
     
  8. Offline

    JDJ

    I use 1 main plugin to run my server. It uses ips to tell if a player is imposing or not. If they are fake, ban hammer. If not... then they get their rank back. I think that Mojang should charge maybe $15 or so, that way the likeliness of these occasions happening is lower.
     
  9. Offline

    Relicum


    IP's are the least unique thing out of player names ip's and UUID's, Anybody from network security will tell you that IP address's can not be replied apon.

    The cost is non or our business. Mojang have stated that the first one will definitely be free and there will be a restriction on the number of changes an account can make and also the frequency.

    Bukkit also mention but didn't commit to it of implementing some form of local look-up system or remote possible. It was only a brief mention by a bukkit staff member so it wasn't official.

    @asofold what have these server owners and developers been doing for the last 6 months, how much more warnings do they need. ??
     
  10. Offline

    asofold

    Couple of problems with that...
    I guess they have been waiting for a CraftBukkit update, in order to know what they actually can do and what they can not do - then they spend time waiting for other (dependency?) plugins to maybe update or not yet update (until this very time !). Then they start considering what to drop and what to get to make at least something work - then they start thinkling about how to do user-interfacing, e.g. if plugins handle edge-cases with uuids differently, or if they think that players just wont remember uuids and still want reliability.

    So many things so easy to come up with, but where do you get 6 months from? Some statements about what to come have have been followed by ... nothing for ... years, still counting...
     
  11. Offline

    Necrodoom

    No matter how much time you give owners and developers to adapt to UUIDs, 1.8 will still rip a lot of them to shreds due to improper understanding of UUID change and its impact.
     
  12. Offline

    PandazNWafflez

    Sadly, this is true. Probably 65% of Bukkit "developers" are in fact not very good at programming and don't really understand Java or code in general, but have learnt how to do specific things within the API and frequently have to ask for help with relatively basic things instead of learning from the source and JavaDocs.

    Another observation I've made is that people are viewing this in a very negative way. In reality, using usernames for stuff was a stupid system anyway.

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

    garbagemule

    "The source"? What source? The source code for OpenJDK? The source code of the Bukkit API? Of other plugins? And JavaDocs were never meant to be learning material, and they definitely shouldn't be used in place of proper learning material for learning software development. Besides, learning from other plugins is a downward spiral of poor code quality, because learning from poorly written plugins (how do you know if a plugin is poorly written if you don't know anything about software development?) is an actual option. Learning software development from just studying source code has never been an effective way to learn anyway. Don't be ridiculous.

    No, Captain Hindsight, it wasn't. It was the most unique identifier for a given player and in no way a "bad idea". It was a unique identifier that was made variable. (Some of) the negativity and panic is fully justified, because it is a breaking change that has to be dealt with. There was no other way to uniquely identify players before UUIDs, so the usernames were perfectly fine.
     
  14. Offline

    PandazNWafflez

    garbagemule When I said from the source, I meant the source of Bukkit. Many so-called 'developers' here will post a thread saying 'WHAT EVEnT is FYreD WEN A PLAYA PICKS UP ITEMZZZ' instead of looking at github and going to the player events package, or looking at the JavaDocs. The same goes for asking about basic methods which in reality they could find by looking at the autocomplete options in their IDE within 5 seconds.

    If people who wanted to develop Bukkit spent 3 hours watching or reading and writing code along with a basic Java tutorial, such as the Oracle tutorials or thenewboston's video tutorials, they wouldn't be so bad at programming. I don't know how often you check the IRC channel #bukkitdev, but so many of the questions there are stupid and are simple for anyone who has any Java (or any other language) experience.

    With regards to your second point, storing usernames is a pointless endeavor for something like Minecraft. I'll give you one thing, when Notch wrote Minecraft, storing usernames WAS the best way to do it, but since the introduction of Mojang accounts UUIDs should have been in place. After all, what if Mojang want players to be able to have different names on different Mojang games (I'd imagine they will)? That's probably part of the reason they took the effort of doing this. And name changing has been requested for years. I'm pretty sure it was around a year ago, maybe more, that they said they would do it at some point.
     
  15. Offline

    garbagemule

    The problem is that both of those sources stink to high heaven, and I see plenty of people here on the forums (and on IRC) who say they learned from those exact resources (or similar), and still ask the same questions. There is decent learning material out there, but Oracle's and thenewboston's tutorials are not it. This discussion is a little off-topic though, and has already been discussed quite a bit in other threads (e.g. here and here).

    I was under the impression you were having a go at people who use(d) usernames as unique identifiers in their databases, not at Mojang's way of handling the situation. This is also getting slightly off-topic, and there really is no point in arguing whether or not Notch should have time traveled into 2014 to figure out which kind of unique identifier he should have chosen for his game, just so the plugin developers for a server modification would have an easier time handling changing usernames... Name changing was not a relevant, desired feature before SMP was introduced, and the modding community is about as old as SMP. Of all the words of mice and men, the saddest are, "it might have been."
     
  16. Offline

    PandazNWafflez

    garbagemule If you are patient, the Oracle tutorials are excellent. I learnt a lot from them, and even now if I don't understand one of the more advanced features of Java I refer to them.

    But anyway, I agree with your point about Notch, I agree that he was justified in using usernames when he made the game. I just think that at this point in time, it's become a stupid way of doing it and storing a UUID is a much better way, even if it wasn't a few years ago.
     
  17. Offline

    asofold

    I am pretty sure, though, that many people who roughly understand UUIDs do not fully acknowledge the problems with user-interfacing and the aspects touching cross-plugin compatibility. I also think that the word stupid is not too well-placed, because the whole system simply just changed , while a second ago "using player names" was the only reliable way to go for storing data and for referencing offline players, we now have changed to having uuids as unique identifiers.

    "Last played as ..." is not always desirable, thus we will have different plugins taking different approaches, leading to ... hopefully seldom but still distinct... trouble.
     
  18. Offline

    PandazNWafflez

    I wouldn't disagree with that. A better way of phrasing it would probably be saying that 'it is no longer a good way of doing it'.
     
  19. Offline

    ZanderMan9

    asofold ""Last played as ..." is not always desirable, thus we will have different plugins taking different approaches, leading to ... hopefully seldom but still distinct... trouble."

    Indeed. Not only that, but everyone from developers to server owners to hosts (and generic backend people) are going to take entirely different approaches, because this is not a problem with a single most desirable, most reliable, and all around best way of handling it.

    The way I see it, this has to be handled in two main areas:
    1. Backend, where the data and code is going to work.
    2. Frontend, where we have the immense task of making UUID's people-friendly.
    Of course these two will have to work with one another.

    UUID's are great for coding, yes, because they allow flexibility in usernames, but from the perspective of people (not machines), they are, quite frankly, a pain in the you-know-where. Moderators on servers running different plugins with different ways of handling this are going to be confused as all Hell. They're going to wonder when they use any command on an offline (or even online for that matter) player, because they don't know who or what they're actually dealing with. They understand that this person had this username, but they wonder how the plugins will react if the username has changed. Unless of course they understand the methods of every single plugin on the server, which is ridiculous to expect them to learn.

    PS Guys, it isn't the UUID's that we are having issues with; it's the switch to them that we have issues with. If it were like this in the first place, no one would think anything of it.
     
  20. Offline

    Zupsub

    That's not right. The problem with UUID is, that you can't remember then (as a human). So you can't ban/kick/op J6HIRB46BSJ7JS78, you will ever ban/kick/op ZanderMan9. And that's the point: what happened if now PlayerB has changed his name to ZanderMan9? You will ban/kick/op him, if you haven't been noticed, that ZanderMan9 changed his name.

    I just hope, Mojang will make it so a username is "protected" for a month (or so) and the UUID of this can still be pulled, even if the name already changed. That would solve those problems easily.
     
  21. Offline

    garbagemule

    No, he's absolutely right. This would never have been an issue if UUIDs had been employed from the start, because as it has been reiterated countless times already, you do not have to remember UUIDs. The problem is the transition, and it's a transition into how you go about making sure you don't have to remember UUIDs. The previously mentioned "last nickname" approach solves your problem with zero repercussions.

    Classic fallacy in Computer Science, young padawan. Your suggestion is a desperate attempt at a workaround, and in no way a solution to anything. A time-based approach with an arbitrary countdown is in no way a good idea when a robust, event-based approach is straightforward.
     
    krisdestruction and _LB like this.
  22. Offline

    _LB

    The nice thing is that Bukkit already remembers the last username of a payer in the player.dat file..
     
  23. Offline

    _LB

    krisdestruction likes this.
  24. Offline

    ZanderMan9

    You know what? I'm not even going to let this happen; it's not something I want to deal with and so I'm going to throttle any connections with a UUID that has a different username than when it first logged into the server. Time to open up Eclipse...
     
  25. Offline

    _LB

    ZanderMan9 Don't forget a person can log on for the first time with the username that used to belong to someone else on the server.
     
  26. Offline

    ZanderMan9

    I'll do something for handling repeat usernames. _LB
     
  27. Offline

    asofold

    I will lock them out until i have fully migrated (for which i do need more info on who some external plugins will do it). After that i might give them extra prefixes like strike-through names :p - which demands them to contact admins to get rid of.
     
  28. Offline

    _LB

    I highly doubt you can honestly say you never ended up with a username you didn't like.
     
  29. Offline

    asofold

    I assure you that players who take over names of other players who have played before on my server.... must be either very silly, or have something malicious in mind.

    Seriously, the fact that people will change their names also means, that very rich or popular players will do so, so the temptatioon is there to take over their names. Since i don't know how some of the external plugins i am using will handle uuids, i will have to wait until i know, if i have to write a custom migration tool also for past players. In addition i need some infrastructure to make the user interfacing (chat/signs) work in (if possible) one consistent way, at least such that players can know what they are doing. Since this all takes time to develop, i have built a database of all past players and will lock out people changing to names who already are known on the server, just for their own safety.
     
  30. Offline

    _LB

    It can happen without either player knowing the other exists.
     
  31. Offline

    asofold

    Of course :) - though it is much less likely with the size of my server, to have many people with "good to use" names who change theirs, including an estimate how probable it is that someone taking the name will join my server.

    I won't lock the mout forever, but plainly... for tzhe scenario i pointed out ("not yet implemented") there is no other choice but to lock them out temporarily.
     
Thread Status:
Not open for further replies.

Share This Page