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

    xize

    Acer_Mortem

    I don't see a really problem though, the only advise I can give is make sure people visiting your project page are aware, just because it may could lead to unexpected tickets:p
     
  3. Offline

    Acer_Mortem

    xize

    The plugin is going to be a private plugin for a server I'm making, so there's no worry about that. Thanks xize!
     
  4. Offline

    asofold

    If you just store data about players without need for a consistent and easy to use interface to address offline players, then converting to UUID should do. As soon as you have commands to address offline players without knowing their uuids by heart it'll get complicated in principle.

    Edit: The problem can happen with online players too, if some players are not aware of others changing names to previously known names. Even a simple teleport can be a problem, then - but won't be for most cases. Still there will be players changing names, and others might feel tempted to change to theirs, just for fun, be it without realizing how long they have to keep their new name.
     
  5. Offline

    SirPsp

    I've started converting some of my plugins to use UUID and it hasn't been too bad so far.

    I do have one concern though, and sorry if this has already been mentioned here.

    It's possible to have multiple players with the same username stored in the player files. If playerA changes their name and doesn't log back in, then playerB changes their name to playerA's old name and does log in, which one will I get with getOfflinePlayer(name) ? Is there a date attached to it?
    If I'm using getOfflinePlayer(name).getUniqueId() to convert typing a name in commands to a UUID, will it get the most recent player who logged in with the name? Because that seems like it should be fine, but if there's no time/date check then it would be a problem.
     
  6. Offline

    asofold

    Intentions seem to be to have the last-used name stored for a player, name lookup probably is slow and i think they want to use a time for using the latest name - without a database that allows efficient lookup by name, looking up offline players by name is a totally stupid action, because in ANY CASE they will have to iterate over ALL files to handle potential duplicate names. So i bet either Bukkit will support a "real" database (unlikely?) or plugin developers will finally start thinking - either way you'll have API plugins for that (which one will which plugin support...) or plugins each having their own database (how many would that be...)~ i will write my own, and try to get rid of as many external plugins as possible, or make a private fork, it is not a too complex plugin :p. Due to user interfaces becoming potentially unreliable i will also have to put in more work to gain trustable interaction using player names.

    Because that is all too much work i might just raise the hammer and disallow players changing to previously known names, in order to buy time, still running name-based plugins.

    Edit: For fairness i have to mention that intentions also seem to be to have a local name cache on the server, i.e. the first local name lookup will be slow. However it seems uncertain to me how all that will be in the end - it seems that in 1.8 "/ban SEFIHWJNEIFWE$"%"&)=(§V$=%UJFI" will lead to a lookup of the uuid at Mojang, potentially delaying the main thread for seconds. I hope Bukkit won't stay that close to vanilla :p.
     
  7. Offline

    TCLG6x6

    so basicly i could try to rename me to Pewdiepie and i would be the only and kinda real pewdiepie in minecraft? wtf....

    i also dont like it when an update brakes my server :/ maybe i shoult stop hosting my server... dont like it when i need to fix something
     
  8. Offline

    PhilipsNostrum

  9. Offline

    !Phoenix!

    Please help me out: Why is that?
    Shouldn't getOfflinePlayer(String name) be the problematic one? UUIDs are our future, so why is the UUID function only a "temporary hack"? If this is not a mistake: How to get OfflinePlayer properly in the future?


    - - - - - - - - - - - - - - - - - - - - - - - -
    Update on 18.04.2014:

    I think I got the idea now; I didn't make the connection between the upper and the lower quote. Looks like we are just not supposed to use the UUID function with CraftBukkit builds < 1.7.6
     
    xize likes this.
  10. Offline

    xize

    I actually agree with this, I don't see how to get a UUID for a OfflinePlayer instance through Bukkit.getOfflinePlayer() aswell, its alot better if the last known names will be used there also for compatability as it there fore also whas a String.
     
  11. Offline

    vagrantmike

    How do we convert prior whitelists to 1.7.8 whitelists? When i run the latest dev build it converts all the other files with no issues. However, it cannot convert the old whitelist. Is there something special that needs to be downloaded for it to be converted?
     
  12. Offline

    Bobcat00

    Which dev build? ("Latest" is meaningless.) There was a whitelist change put in 3051, and they're now up to 3055.
     
    garbagemule likes this.
  13. Offline

    vagrantmike

  14. Offline

    Bobcat00

    It's 3055, that's all you had to say. Don't know about your error. Report it to the CraftBukkit team.
     
    garbagemule likes this.
  15. Offline

    WeeziMonkey

    I feel like we're counting down untill the world is gonna end..
     
  16. Offline

    ZodiacTheories

  17. Offline

    JHG0

    Oh....UUIDs, what fun
     
  18. Offline

    sackboy_lbp

    Why would Mojang do this? I don't think I will be able to run my server now, if they are going to go and change it like that. I could care less if I could now "change my username" whenever I want, I don't care what I look like!
     
  19. Offline

    xize

    I'm actually worried about this scenario what if:

    player has a non migrated account on a email through minecraft.net, but also has a other account migrated on that same email through mojang.com?

    it seems I got that but I'm not sure if I got double UUID's now... already sent a email to mojang also to clarify if non migrated accounts are able to be picked or not when the name change feature comes out.

    because of this:
     
  20. Offline

    TheCoders

    if u have 2 accounts u have 2 UUIDS
     
  21. Offline

    asofold

    Not migrated accounts - the names can be taken by others at some point? That would be another unpleasant thing to happen, especially if their uuids are not staying. I assume the surprise-factor to be slightly higher with this aspect :p.
     
  22. Offline

    xize

    asofold

    yeah I'm not sure about that part though maybe I miss understood I got it from by reading EvilSeph's General notes on this thread.

    -edit-
    I got awnser to my mail from mojang:

    and this one:

    so I think that is a scenario less atleast I hope:p
     
  23. Offline

    asofold

    If i had known they have email...

    Sounds great!
     
  24. Offline

    LegendaryStarX

    So pretty much we can't or at least shouldn't use any un-updated plugins anymore. Which means half the plugins are doomed.
     
  25. Offline

    asofold

    You might even be doomed (personally) with updated plugins :p - assume they use different paradigms for which player to reference under what circumstances (pretty short version).
     
  26. Offline

    kairispaz

    Sounds like there needs to be a group plugin update project or something at least on a few of the useful ones. (Also, an icon or tag or something for plugins that are already updated to UUID? Just a thought.)
     
  27. Offline

    RedstonedMiner

    Did it add the commands that 1.7 added?
     
  28. Offline

    Wizehh

    What's wrong with using the OfflinePlayer? Does anyone know of a viable alternative that I can use?
     
  29. Offline

    asofold

    This now depends on the version of Minecraft/CraftBukkit. Since idk... at least since 1.7.9 the player data files are stored by uuid, so getOfflinePlayer(uuid) should be similarly fast as getting offline players by name used to be when player files had been stored by name.

    To get the OfflinePlayer by the other (uuid if stored by name, or name if stored by uuid) would be the expensive operation in theory, because you would have to look through all files to find the right one. Could be that things change slightly with a local cache, provided it's synchronized with player files - some plugins/servers delete those on a regular basis (e.g. mini games, or using databases to store player data somehow).

    For my plugins i will rather store uuids+names with the relevant data (if any), because i don't want to rely on a potentially changing or even useless local cache. For some contexts one would needs the latest data about a player, so one has to look it up at Mojang somehow. But of course all that is extra work to do. So what i am doing to know who played on my server during the past 5 years (was it 3 or 4 :p), is to fetch all names from all sorts of sources and look those up at the Mojang API, so i do have the "original" players stored somewhere. From then on i can deny/grant access in a consistent way, for legacy stuff that goes by name. Of course i need to implement some concept for name changers (also old players just changing) to keep their property, but at least i can track the property back to the original owner then, so it is possible in theory :p.
     
  30. Offline

    Lifecraft_R

    1) Name Changing seems kinda crappy... it's gonna be hard to remember people, if they change their name- who wants to remember a hexadecimal?

    2) Do plugins from 1.7.x break with the 1.7.9 builds, especially Ultimate Survival Games and TnTrun, as they us names.

    3) Almost forgot to mention my 1.7.5 Iconomy- will I have to redownload dat too? Does it autoupdate? So many questions.....

    4) <Insert Question Here>

    5) This has probably been asked before, but so what?

    6) Enjoy this pineapple, and a wierd post. (The first three things are valid. Ignore the rest, it's junk. Half the pineapple got cut off.)

    Pineapple
    o. `so
    ..............................o. `so
    o+` .yh/
    +o:. .ydd- `
    `` /o+:` .sydh` ./`
    .. :. :so/-` `sohhy -/:
    `:. .s+. -ss+:- +sshhs ://.
    `::. -ys/-.sso/-. -soyhh+ `://:
    -+:` +yso+oso+:-. `ssoyyho. `///+`
    -+/. `yhsoooso/:-.+oosyyyy+ .//++- `.`
    .+o: :yhsoo+o+/:-ooosyssyo..///+/ `..
    ` `+o/` `shhyso+o+/::+osssyyo////++` `::`
    -:.` `/o+- +yhhyso+o/::+syyyhso+///+- `//-`
    .oo/-``/ss:-hhhhysoo+/:/syyhhsso//+: :s/.
    `:sso/./yy+yhhhysssso//shhhhyso///`.sy/` `..
    .oyys+ohhhddhhssyyhssyhhhhyss++./dy/` .-:`
    `/hhyyydmmmdhyyyhhhhsyhhhyss+/smy:` `-//.
    `` :yhhhhdmNmdhhhhhhhssyyyyysodmy: `-++-`
    `:/-` .ydddhdNNmddddddhyssyyyyydNh:` -+o/` `..
    .+o+:` `sdhdddNNNmdddddhyssyyshNd+/ooso-.-:++/`
    ./yy+-` :ddhhdmNMNmmmddhyysyssmmddhhyo/+oso+.
    .+yhs:`hddhhhdNNNNmmdhhyyysymmmmdhyyyyso-
    .--.` .+hdysmdddhhdNNNNmmdhhyysdmmdhhhhyys:` `.
    .+so+:.-sdmmmmmmdddmNNNmdddhhhNmdhhhhyy+` `-+/`
    -oysso/ommmdmmmmddmNNNmmmddmmdddhhhs. ./ss-
    `:yhhyyhmdhhhdmmdhmNNNNmmmmddhhhhh:.+ys:` `..`
    `+hdhhhdddhhhhdddNNNNNNNddddhhhs+yyo.`-:-`
    .``` -sdddddmdddhhhdmNNNNNmddhydhhhhy+/+/-`
    -oso+/-`:ymmmmmmmmdddmNNNmdhddyshdddhss+-`.--.
    :syyhys//hNNNNNNmmmmmmmddddhsyhdddhs+/oo+:. `
    :yddddhshhdmNNNNNNmmmmmddhyhmddhyyso:-::::.
    :hNNdhhhhyhhdNNNNmNNmmdyhmdhhhhyssso:.`
    ``..`/mNmdddddhhhmNNNNmmmhhdhdddddhs/. ````
    `.:eek:yhhyymmmmmmmmdddmNNmmdddddyhddhs-.-::-...`
    `.---.```-+ydmmNNmmNNNmmmmmmmmmmmmhhddyoo/.
    `-:+oso/+ymmNNNmNNNNNNNNNNNmmdhhhys:---:-..`
    -:/+oymddhdddmmmmNNNNNNNNmmmdddddyy/-`
    `..-+hmNNNNNNmmmmdddmmmNmmmmddmh+:::...`
    ..``.-/+smNNNNNNNNNNmmdddmmmmmmmmds:` `
    `.-///sydNNdyhmmmmmNmmmmdddddddmds+-..`
    :/+ydmdyhmNmdmmmmNNNmmmdmmh+/+s+-.`
    `.-+yyyoydymmhhNNNNmds/yhysmhddhs//-.
    :yhhhyysyooyhdo+/++//+yyhdhsoy+hNd-+-:`
    -yddNhyyss+shmmhhsyossysoo/o+//::+yo/:/-`
    /hhhdms++o//oyhhddyssyo++:--///+/+/ho++/-:--`
    +hyhdmhyyyhshhddyys+oyydo///://oyoo++:-::/+:-`
    /yyyyhdmmmddddyhys+oooyoyssy+o+hyo:///o/:::/:--
    hhhdhhmdhhhhhdds+//+osooyhhsyhyyo+//+/+++oo//:/`
    .hddmmmddyyyyddmhyys+oyhyysy+++ho:-::::-/y+/://:-
    /hhyddmysysyyyhddmdmyydy+///:/++yy++sssooh+//+/+/-
    .hhyyhdmdyssyyhdhhyoydhsso+/+so++oys++++/os:--:++/-
    +hdssyyhddhyddhyssoossyds++syhso+sdo:::/-+so//++://`
    yhhyyhdmdmdmdyysssooyssdyyyhhhysshh+/:/+//+osoo+////
    /yydmdmdhyhhmmyssydyssssdds+//+///+hy/---/+o++/++::/:
    `shhhdNhyyhyydmdhhhmmdhyyddho+y///++sdsooosy+//o:s+/+-
    `shyyhmmyhhyshmNmmdhhhyysmdso++:/oo+shyyssyo/://:+++/:.
    -hhsyymdhdddhdNNddsoosshhhmdo+++soyyso/+//ss/:-:/+::-/`
    :yhssyhddyyhyhmmhyyyyhyhhhmdhhyyyymys//o-:/ys+++/:://:`
    oyhhddmdyoshyhddmysoosyyyhddhsyyhys+//+/+osoosy+:-:/+/.`
    oyhyyhddoooyyhdmdddhssydhhhsso++ohh+/::shooosso/::eek:/++/.
    :hhodydmhsosyydmmmmdmhdddyo+/+/+osmsossyooo-:+s/--:++:-
    .shohyhddhhhdmdddhhyydhsyyyo/osooshydddo///.-:eek:o/::///:
    .shossydmmmmmdhyyosyhhdy+//+syoososyyys+:eek::::/+so++://:
    +yyyddyddmmhhyho+soddmdysosyhhdhoosso:---.--:eek:oso/-///
    `osdddy+hyhdmyssoossyhdhhddddy+os+/++hh+/--:+++/+o::::/ `
    `shhyoohyyhmdhsossshyyydddhhso/o+/+oydy+++y/////s++//:.`
    +ssyoosyyymddyhhddmdhyhys++/+://///+yhyhsyo//-/o+os+-`
    /hyhhsoossydmddmdhhyyssshh+/:-:/:/+oyhy+/://:::+oss:
    `shshysyyhdmhyhhyys:/osyhmdss++ssoyooosys/:---://++`
    `-/sosyhhsshhhhyoosy/+y+ohhyhhsydyo+o/:+shs////+//-:
    .-ossyyysyysyhdho+/+oso+oosshdyos//s-:+oso+/+++//::`
    :eek:sss+ssoyyhdmyoo+osydhyhmhs+//:+://:/+o/:://:::`
    :ssss+oossyhdhdyhdhyysyyysys///::////+o//::/+:`
    :yssooosooooyyddhsooo+oooodso++///:/+/:+/+/-`
    .+ooo+ooosoyydhso+/+/+oooss//+++/:/::::/:.
    -/oooossyyysssssso/+//+////oo+/+/::::.
    -/+ossssyyyoo/+ossooso++++oo/:::-`
    -+ooosyhsssysso+o++ooo++//-`
    ```.-..-..`````
    /spoiler]
     
  31. Offline

    xize

    Lifecraft_R

    1. I sort of agree with this however, some plugins already are compatible with UUID's some are not, note not every plugin has to be converted to uuids only when you have important flat files or database to work with such as permission groups, and other user data, but name usage still needs to be used in the first place because the player cannot change his name actively on the server he needs to reconnect then to make the name change effect so that means you can depend on the name but only if the dev makes a good wrapper around it and update things acordingly when the player joins.

    2. I don't think these 2 plugins will break however I don't know if it saves ranks or kits so its a yes no situation however I guess these plugins has active developers, but some plugins are abdoned.
    but my concern is more the server breakage since I noticed several shared hostings including the one I use which doesn't aquire multithreading which means lots of troubles keeping the server up because it checks for their UUID's in a slow web request which could take alot of resources and is server blocking when players are joining.

    3. that is actually my same concern atleast with iconomy7 or 6, the plugin is very old but I'm unsure if it would be updated though but on the other hand we have Vault which makes alot wider compat between different economy plugins which means other plugins can still hook in a other economy plugin which is updated with uuids.

    ive made my own conclusion just to keep my server abdoned for a while:p
     
Thread Status:
Not open for further replies.

Share This Page