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. If you need to store data for players, e.g. money or property, then you should try to get all the UUIDs for past players now, because migrating later will mean data loss. Even with fetched UUIDs, migrating plugins later means that someone has to feed them the old/original UUIDs, preventing them to look those up at Mojang.
     
  3. That's right. Say 'xize' changes his name to 'xsize' (because he made a typo), then Bobcat00 changes his name to 'xize'. Then you start your server. 'xize's data gets converted to my UUID. I get all your stuff!
     
  4. One thing I'm still unsure about:
    What if players can and will change their name, but you still run an older server version, say 1.6.x or even 1.7.2, due to a mod(pack) being out of date?
    Can you still prepare for UUIDs? Because those versions don't support that yet, right?
    So basicly what can we do for those modded servers?
     
  5. If you run old versions, someone who changes his name will be treated as a new player. And another player who changes his name to the old name of the first player will appear as if he was the first player.
     
  6. Offline

    Werioco

    [chest][chest] I run an offline minecraft server with AuthMe; will this problem affect me?[chest][chest]
     
  7. For one, offline servers are not supported.
    For two, it affects ALL of minecraft.
     
  8. I'm honestly waiting for the build that un-deprecates these. It's annoying having 100 warnings in my IDE.
     
  9. Apperently it has an interesting effect when running offline server in development phases.

    If you switch from offline to online mode the names will be converted. Once you are online you cant switch back to offline since the data would then be lost since in offline names are used instead of UUID for data storage.
     
  10. Offline

    DrPyroCupcake

    lycano I didn't know that, probably because I don't use offline servers :p Very interesting though.
     
  11. Offline

    morshu9001

    No way we could have seen this coming, but it would have been better programming practice to make a generic "player ID" object that encapsulates all comparisons and has to/from unique string and from player methods. We would have only had to change a few lines of code if we had done that :S

    If only they had instead left all the usernames alone and added a "nickname" property to each player!

    evilmidget38's UUIDFetcher seems to be out of date with Mojang's API and isn't working. AGH!

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

    pwnpk23

    I am kindof shocked no one has thought of this here...
    What is on my mind:
    Each player that enters gets a unique number assigned to the UUId and saved.
    When a player joins the UUIds will be matched and the username will be assigned to the number.
    When the player has a command execute: /ban player... the username will be matched to the number, thus cutting out some use for UUIds in game almost.
    This lead me to thinking that making a table is MySQL would be boosted by this since we can increment our table every player that joins. Ex: play 1 joins first. he is assigned as 0. play 2 joins second. he is assigned as 1. and so on.

    I don't really mind when a player joins my server to get the UUId and username and all that.
    I can restrict his IP from logging in for x amount of seconds so there is not a server bomber.
    Though honestly I think the client should get the UUId and transfer it over to the server along with the current username.
    It would save the buttload on Mojang and for us a whiles away from Mojang's servers.

    I would love to lead a discussion. PM me or what not.

    By no means is this statement wrong. I actually think this would be better.
    Or they use MD5 instead of UUId

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
  13. I can see what you're thinking: something akin to a cache. But there are quite a few problems/inefficiencies with your method:
    • Transferring from username to number to UUID is inefficient; you're simply adding more overhead that is not needed. Why not just use a HashMap?
    • Bukkit locally caches player's UUIDs upon login. It's efficient simply using Bukkit and won't cause any extra delay. All you need to do is take the UUIDs being stored and 'restore' it in your own cache (see above) since Bukkit deletes the UUID when the player leaves the server (to my recollection).
    An MD5 is a hash, meaning it converts a readable phrase into an arbitrary - but consistent - phrase/conjugation of random letters and numbers. MD5s are based off of something. UUIDs are not; instead, they have no special attachment to a distinct phrase or word.

    But building on what morshu said, it would be nice if players had a fixed username and then a changeable nickname. The nickname would be what appears on servers but plugins/Bukkit would have access to the player's username as well for data purposes. The username could be encoded into an MD5 hash if that's what you mean.
     
  14. Offline

    SuperstarGamer

    It is permanent, no time limit for it you have it until the end of time ^^
     
  15. String length, not lifetime.
     
  16. I see one plugin I'm using stores the UUID as a 16-byte binary field.
     
  17. If you just need the UUID you can use this: http://www.foldager.me/uuid/notch
     
  18. Offline

    Karatechopninja

    I seem to still be getting errors using Player,getUniqueId(args[0]); Player gets underlined red. -.-
     
  19. Offline

    Dakis

    "morshu9001 said:
    If only they had instead left all the usernames alone and added a "nickname" property to each player!"​
    I also 100% agree with this "smarter" solution to name changes than the nonsense Mojang is trying to pull with these UUID's. Well I guess the word I used "nonsense" could be rephrased as "strategic" since Mojang knows exactly what they are doing with this adjustment. They 100% understand that it will end up shutting down a huge chunk of people servers and in turn make their "Realms" option get more customers. In the end all companies are just in it for the money but I truly believe this UUID garbage will end up coming back to bite Mojang in the butt. Mojang needs to be careful about how the userbase views Minecraft as a whole. If they piss off half the server owner user base by forcing their servers into offline mode once the name changes are available, it will make waves that may ripple users into other games and away from this company. There are many competitor sandbox games getting into mainstream now-a-days and Minecraft is no longer monopolizing the niche. Remember "New Coke" and the damage that did to Coca Cola.. ? It took a lot of bandaids to fix that mess-up and it will take a lot for users to want to come back to minecraft after this BS goes live. Think about it.. a server owner isnt just 1 person.. shutdown their server and the entire community of players that frequented that server will also feel the flack from this. A player on a server invests endless hours into all of their personal builds and when Mojang hits that switch to push 1000's of servers into offline mode, those players will not be able to get their builds back. Thousands and thousands of people will be very very unhappy with Minecraft/Mojang and there will be nothing some server owners will be able to to. Some servers simply have too many plugins that will not function after UUID goes live and they do not have the resources to change everything. Mojang is 100% aware that they could have made changing names much less game breaking for server owners but they are doing it this way intentionally to push more people to Realms. Oh well.. it was a fun ride while it lasted. On a side note Mojang may not have thought how this will impact the developer community as it will end up pushing a lot of plugin developers away as well.
    Too bad Morshu9001 doesnt work for Mojang so there could be some common sense in the mix during big discussions like "how do we let players change their names"... Ummm.. I know.. lets re-write how all databases work so it breaks half the servers that are live now...
     
  20. Offline

    Necrodoom

    Dakis erm.. UUIDs will not suddenly make realms the only useable server host somehow or break servers. This has absolutely nothing to do with realms, not to mention realms are not designed as an alternative to other hosts at all, being closed box servers. Not to mention that there are MONTHS till 1.8 arrives, and months already passed, so the only plugins who could not update are these who are inactive, which means a large part of these would die, UUIDs or not.
     
  21. Yes, but how long until Mojang starts allowing name changes? That's the deadline for plugins being updated.
     
  22. Offline

    Necrodoom

    Bobcat00 I would assume 1.8 or later? They can't allow name changes on 1.7.x.
     
  23. The plan as I heard it is that naming changing will be allowed shortly after 1.8 is released. So, in a couple years.

    And for all those that think there should be nicknames, that's a terribly hacky solution that will cause more issues than you think.
     
  24. There's nothing more "terribly hacky" about a username/nickname scheme than a UUID/nickname scheme. What absolute nonsense. Both schemes represent a logicial separation of identifiers, and in theory, there is no difference. If you want a little bit of credibility, you may want to consider actually providing examples. That said, I agree with you. The username/nickname scheme does come with additional issues. Read on to find out what they are!

    Onwards...

    I reserve the right to be a little rude here, because the fear mongering and ignorance in this thread is driving me nuts (I could stop reading, but my will power is pathetic). Those of you who think you know better, you don't. You just don't. So please stop pointing fingers at Mojang and acting like they're stupid and didn't think things through. And stop with these ridiculous, over-complicated, insane ideas to work around this change. Work with it, and everything will be just fine.

    The username/nickname scheme is idiotic. People who think it's a good idea clearly haven't thought things through. The entire purpose of the UUID change is to create a logical separation of identifiers, and one of the major pros of UUIDs is that the difference between the unique identifier and the nickname identifier is perceivable. With the UUID/nickname scheme, you know exactly which set of identifiers you are dealing with when you are given an element. If you are given a name, you know it's a nickname. When you are given a seemingly random string of hexadecimals and hyphens, you know it's a UUID. With the username/nickname scheme, you have no clue which of the sets you are dealing with when you are given a name.

    The player with username Alice changes her nickname to Bob. The player with username Bob changes his nickname to Alice. A player with name Alice logs on your server - now what? Do you call the getName() method? Or does this method even exist anymore? Is it now getUsername() and getNickname()? What do you do with your databases? How do you know if a player entry has already been "converted"? What should happen when you type a command that takes the name of an offline player as its argument? Is it the username or the nickname? Should both be possible? How do you distinguish between them? No, the username/nickname scheme is not a good idea. It's a pathetic, childish attempt at making Mojang look stupid for making a change. What bothers me the most about all of this is the amount of people who call themselves "developers", crying like babies over changes that require them to take action (and those of you complaining about having to "rewrite everything", re-evaluate your software design and learn your lesson). Welcome to the real world, buddy.

    As for the actual transition in terms of databases, the solution seems pretty straightforward to me. The lookups are already possible, so the transition can be done in one go, either as a laggy one-time thing while the server is running, or completely offline. Adding a 16 byte binary column, fetching UUIDs of all player names in the databases, and inserting them in the new column should be all there is to it in terms of preparing the databases. For the sake of limiting communication with Mojang's servers for lookups, a solution of a "last nickname" column is trivial. The program logic should require changing no more than a few lines of code in the DAO (and again, if lots of changes are required, it's probably time to re-evalute your software design).

    And yeah, server owners, you are going to have a rough transition period, especially if you employ a metric shit ton of plugins (in which case a nice Spring cleaning may be in order, or maybe you need to re-evaluate your setup and stick with the bare necessities for now). It sucks, but whining and fear mongering is going to solve nothing. The best thing you can do is prepare for the change by figuring out which of your plugins are affected, and which of the affected plugins are ready. Look for alternatives for the affected plugins that aren't active, or start community projects to have them picked up for maintenance by other developers (inactive plugins will eventually die out anyway, with or without the UUID change).
     
  25. You said everything I wanted to say and more, thankyou.
     
  26. Offline

    ZanderMan9

    garbagemule I agree. In fact, I think the switch is a good thing. It will break the "norm" and force even the most powerful servers down a notch. Server owners who are willing to improvise, adapt, and overcome will be the ones with the successful servers. People who just throw, as you said, metric shit-tons of plugins at their server in hopes of attracting similar amounts of players, will be disappointed. And who do we want being successful? The former, hardworking people, or the latter, throw-shit-together people?

    That brings me to another point (that may have its own thread in the near future):
    Servers like Hypixel, HiveMC, and MinePlex are going to suffer some serious losses because of ALL the plugins they have that rely on lines upon lines of this: Player.getName();. Trust me, they need the losses. And then they'll get hit by the EULA truck, which is clearly destined for them, if not manufactured because of them. Mojang is right in tightening up on their terms, because thousand dollar packages? I mean, come on, talk about being greedy.

    And those ridiculously expensive donor ranks aren't even my worst concern. The Minecraft community is going downhill because of all that goes on in these servers. Players expect everything to be along a set path, every server to have a (yeah, thanks for reminding me of this phrase, I love it) metric shit-ton of minigames. Little kids don't even understand the survival aspect of Minecraft (which by the way, is its very core) because they think that Minecraft is minigames. Do you see any survival server having over 1000 players online constantly? I don't. All the owners of these servers have to do is sit on their asses and let the money flow in and the devs type away making new minigames that feed off of YouTubers' popularity *cough* Castle Siege from MinePlex having CaptainSparklez *cough*.

    And let's take a look at simpler servers' owners: Work hard to perfectly configure plugins and balance the gameplay and become popular without a massive budget to work with. Their staff, who they actually care about, who work to moderate the crap that happens to come over to their server after swearing their mouths off over at one of the big minigames servers. They have to deal with ingrates and kid-douchebags hating and disobeying the rules on their server. I have firsthand experience, and I can say that more players got banned from my server than stayed, because of pissy attitudes bred by parents who actually buy their kids these ridiculously expensive packages, and all the inappropriate language on the huge server, whose staff do nothing to moderate it.

    Maybe I'm ranting, maybe I'm just putting the truth out there. You might not like it, but the next generation is going to be terrible...

    I think a solution to this is simply a very smart database. Everytime a player joins, it creates a field of that player's name. The UUID is then gotten and stored along with that playername. If a player joins with the same username and UUID, no action is taken, if s/he joins with the same username and a different UUID, we know someone stole someone else's name, so update the UUID. Every week, clean up month+ old usernames and their respective UUID's.
    And then bam, access that database on any command that requires a player name. That way the username will always have an accurate UUID with it.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
    xbenas likes this.
  27. I don't think that's the proper way to deal with things. The UUID is the unique, fixed identifier, and the username is the variable. You should not make database logic that depends on the username. I also don't really understand this idea of "getting" the UUID - it's already available for all online players. When a player logs in, you have access to their UUID right then and there. There is no "fetching" involved. You just called the respective method and voilà. You should not be making username vs. username checks at all. Like I said in my previous post, the transition is the troublesome bit, and it's really just a matter of a simple one-time conversion.

    Fetching is only relevant when you are dealing with players who aren't online, and it is never "safe" to look up a UUID of an offline player, because you can never know if they changed their name and someone took their name in the meantime, but that's just how it is. The point of the "last nickname" column idea I presented is to provide a "safe", local lookup mechanism, so you can do e.g. "/ban garbagemule" without worrying about me changing my name and someone else taking it, because you'll still have my UUID in your database mapped to my old name. In other words, you should not be changing the UUID value for a player once it's been set, only the "last nickname".
     
    _LB likes this.
  28. Offline

    mbaxter ʇıʞʞnq ɐ sɐɥ ı Retired Staff

    Removed several offtopic posts discussing monetary offers.
     
  29. If you need to display a name, make it assume that the name has no relation to the actual player, and reference that player by the UUID, the whole point of a human-readable name is purely to be human readable.

    There shouldn't be much more to it than that!
     
    Relicum likes this.
  30. Sorry, I'm having a bit of trouble understanding what you mean by this. Make it assume? What's it? And how do you reference a player by UUID if you don't have a UUID? There are two main challenges in this thread:
    1. Making data persistence systems UUID-aware and -compatible, as well as resilient towards name changes.
    2. Making plugins that allow users to reference players by name (e.g. via commands, signs, etc.) resilient towards name changes.
    From what I can tell, all you're saying is that plugins shouldn't, internally, be referencing players by names, but by UUIDs, which is trivially true (and a non-issue). The problem isn't plugins, though, but users. The two challenges aren't impossible to solve, but they aren't trivial in the general case.
     
  31. As codename_b said its so simple, just forget about names completely there used for display purposes nothing more. It makes no difference if a user changes there name 50 times, all that is required a simple DB update if the UUID and names don't match, that's it. If your having trouble seeing or understanding that, you have been living in minecraft for to long, step back out into the real world and you find that all DB's uses a primary identifier be it storing airfares, hotel reservations everything or your local library.

    @ZanderMan9 sorry friend going to have your spoil your self satisfaction in in forming everybody that MinePlex and Hypixel etc are going to struggle to cope with it. Sorry but I know for a fact HyPixel's server has been ready for months, Agent-Kid one of their lead dev's announce on their website months ago it look approx 4-5 hours to convert all 3.5 million player records.I suggest you concern yourself with your own server as it's clearly getting you a little hot under the collar for you. Your also highly miss guided when you think due to mini games its killing the community, players play what players want to play. As you pointed out there are greedy owns out their , but don't you think if players wanted to play survival they wouldn't be offering it to them ?? Minecraft evolves in its own way, even mojang have hired dedicated developers solely tasked to write mini games for realms. By your reasoning your insulting all the players for not being able to make up their own minds on what they want to play. I couldn't give a monkeys what servers choose to charge we all live in a free world and just go to another server. We live in a world where people just don't take responsibility for their own actions. Apart from the thief s, where do most players get there money from ?? As the average age is 13 , it clearly comes from the parents and if their stupid enough to pay $1000 that people are claiming well more fool them. Nobody is holding a gun to their head.

    Haha my rant over.

    I user can not change their name while logged into your server, they log off and log back in gain with a different username update your records and carry on as your were referencing them in game for commands etc its only persistent data that you must store using the UUID as the primary identifier, all the permissions plugins, well the main ones have already updated, you many be using usernames to add permissions but it is still storing them against the UUID and will quite happy update if the records don't match due to the user changes their name, without you doing a thing. People have and 6 months notice and warnings about this if they still don't understand they shouldn't really be providing plugins in the first place, or if you don't understand "Google is your friend". By the way that last bit was not aimed at you or any one in particular.

    ZanderMan9
    I think you don't quite understand how is a player going to steal another players username ??? It is not possible for that to happen. A player can only change there name to an unregistered name. By that if you change your username it no longer belongs to you and is made available to anybody else. Thus theft is not possible.

    Also your smart database is not very smart. I do think it wise to keep a record of changes a user makes. But this is done by having a separate table funny enough linked by the UUID that lists any last usernames a player has used. Until you can let go of this need or thought pattern that usernames are the most important thing your going to drive yourself mad. Also be realistic there is close to 20 million PC clients the odds of this having any effect to a server are so slim. When I say effect I am not meaning in a harmful way. I have managed one database in particular that held close to 13 billion records and you don't have issues regards uniqueness or confusion over what record is connect to what, provide of cause it is implemented correctly.

    A prime example is Governments hold records on their citizens, these citizens regularly move house requiring the DB to be updated and they don't have any issues with it. If that doesn't re assure you that people are panicking and talking to similar people have no clue as to what it means they just make it worse. I am presuming you are a server owning please let me assure you from having near 20 years in IT you best listening to what developers are saying rather than argument the pros and cons without the knowledge to provide a relevant argument. By all means ask as many questions as you like as its what a good server owner should be doing, But trying to debate on a technical level won't get you very far. Having your opinions and taking about them is all good and well but it would be like me arguing the best way to land a jumbo jet, which I know nothing about.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
     
    Last edited by a moderator: Jun 7, 2016
Thread Status:
Not open for further replies.

Share This Page