PSA: The Switch to UUIDs - Potential Plugin/Server Breakage

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.

 

Why does it matter how the player names were put into the file? Whether they were added m a n u a l l y or by command, they are inside the file the same way. Minecraft should automatically take the player names you currently have in the file and convert them into UUID form.
Ideally the whitelist file would be checked for normal player names and update them to UUIDs every time the server starts, but I don't know if it will actually work like that.

 

I know there's not too much information from Mojang, but it was known that (i guess) the majority of plugins will have to change a good while ago, so you guys could have made a PSA with less information earlier. Less info is better than no info

I recommend reading the issues (both open and closed) + comments for the AccountsClient.
#2 discusses some potential cases and problems including, some of the comments are from Mojang.

 

Just another sign that mojang are complete and utter fking retards

changing name is something that should be handled server side, not from mojang account side with uuid stupidity.

If a player xxShitxxName99 wants to have a different name , then the support for changing a players name should be handled by bukkit server or mojang garbage vanilla server. Not from the premium authentication level, ie the server should have a lookup file for old and new usernames. Where the getPlayer name api etc just uses that to check if there was a change from the name provided by the account when joining the server. like

xxShitxxName99 = BetterName22

So many plugins just store players username, not uuuid crap, and who wants a config or player.yml files with uuids, and the delay with checking uuid's from mojang garbage servers is just another issue.

All this tells me is that running a offline server with local authentication is the way to go, where players already have the freedom to choose a fking name they want and have done for years. And server admins have the control over it, and it doesn't effect the tons of plugins that work with playernames.

Premium players have wanted a way to change there name at mojang account for a long time, something mojang could have handled without inserting uuids into the mix, and just allowed a name change if the name was available, continuing to send the auth info with the new playername, not a fking uuid, mojang in there blitheering stupidity with the clowns that work or twit there have found a way to piss everyone off,.... can they get anymore retarded and slack.

I'm still waiting for a them to update the rendering engine after the broke it 2 major versions back when Anti Aliasing used to work, before they added there shitty shaders and broke force AA render.

FUK U MOJANG

 

Dang that's kinda disappointing. You'll never know if a real YouTuber is in your game.

 

They can only take over the exact name if the youtuber does not have any name or has changed the name as well - however as i mentioned above the trolling use case is to use a very much similar name to that of a youtuber, so that's still an unpleasant aspect.

 

What happens when the player has never been on the server? Will getOfflinePlayer(uuid) just request it or will there be another method for that? getOfflinePlayerThatHasNeverEverBeenOnTheServer(uuid)

Edit: just noticed the username.dat, which will be converted to uuid.dat doesn't include the actual username. So I guess you will need to add that. Otherwise it wouldn't be possible to get an offline user's name.
I know that the username might be outdated, but I guess the last known (known to the server) username is more useful for a human than a name that was never seen with a user

 

Most likely it will be the same as getOfflinePlayer(String) is now, but instead OfflinePlayer.getName() will be inefficient, where as right now OfflinePlayer.getUniqueId() is inefficient. Basically they will swap which method does the web fetching when the player files are updated to use UUID.

 

So you mean getName will make an API call every time? That's horrible, really. That would mean it's damn slow cause it's either blocking or you need to wait for the requests to finish. Also it wouldn't work when the mojang servers are having issues again.

 

Anyone have a idea how Buycraft will change with Charging back usernames and old donor names?

 

Thank you very much ampayne2 for re explain what Alshain01 already so adequately has enlightened me of. While ignoring the fact that FerusGrim repetedly encouraged me to update a plugin that I do not have.

Sincerely Magnus Fransson.

 

1) We haven't decided how we'll handle this yet, but we'll most likely have an explicit method that needs to be called which will perform a web lookup if all other lookups fail. This is obviously because web lookups are expensive in comparison.

2) We've already added lastKnownName saving to the player.dat files, but again this requires players to have joined the server at least once.

 

May I suggest that you record in the required files when a player's UUID is added. If a user has a name on the old whitelist, but not a recorded UUID, then request from Mojang the UUID from the date of the name being added. If there is no recorded date, take it as the date of the file. If there is no UUID for that name at that date, then use the current UUID for that name. This will require Mojang's protocol to allow UUID searches with given names and dates.

Hope that is meaningful.

By the way, I think that part of the problem that people are having is that they expect things to stay working the same way. One example is the assumption that if there is a whitelist, there will still be a whitelist ASCII file. I suspect this assumption is false. Dinnerbone said on Twitter:

Sorontar

 

Guys! 1.7.6 fixes this whole problem... so calm down!

 

Hardly ! It can't fix everything that this change does - but i am sure the Bukkit team will do something to help plugin developers a little bit. There is hardly a pleasing way to really fix things, like how to address players on signs or offline players with commands now.

On the one hand someone changing the name takes a risk on their own, on the other hand the trolling potential with people taking similar names is "more real" than before. For some people, like who got their account by the grace of... say parents..., or who chose a name longer than 14 characters, it could be appealing to change the name, so changing names will just be normal - then taking over property or access to stuff in a malicious way is a valid trolling/griefing scenario.

Example ways to deal with the change for some aspects:

Using UUIDs instead of player names:
Pros: Simple to implement.
Cons: Unplayable. Players won't remember these, name + uuid means more confusion than good.

Using account numbers/codes:
Pros: Potentially short, fit on signs (unlike the longest of player names), similar to bank accounts in real life, might be easier to remember than some of the player names.
Cons: Cryptic, does not show the involved player name directly, Some can't remember even shorter codes, typos are a problem. Virtually every plugin will have an own way of handling these by default, a central API/support seems unrealistic from this point of time - while there are thinkable solutions/ways, they likely take a long time to develop, thus certain plugin interaction could suffer a bit, and just won't be there for a while.

Using player names as before (rather for easily changeable things like shops, access signs):
Pros: Simple ! Seems a fair trade: Player changes names, player cleans up the signs.
Cons: Players have to change all signs on changing the name. Not good for really important stuff anymore, also thinking of long time players ("dear to me"), vegetables ("here anyway") and donators ("here for a reason"). As mentioned above, changing names makes sense for players with >14 characters long names and with names that were not under the control of theirs / their brains at the point of time of getting Minecraft.

Some of the remaining problems, even if doing "something":
Hardening the user interfaces against abuse, making them trustable ~ some randomized q/a:
- How to "track friends", just on the server, without relying on governmental or commercial services?
- How to distinguish similar user names with numbers in it?
- A "history of names on this server": could help to list related player names and uuids either way, to make it possible to see if this player is who you think who he was. Probably some server owners want the possibility for players to opt out from having their past-names referenced, though. Also it is uncertain how acceptable it would be to call this extra command all the time, or to insert it in contexts that might pose trouble, which then again means that some plugins might do it, some might do it in a different way...
- A "trust-framework": meaning a per-player option to trust a certain other player, could be a useful addition. This allows to use the player name in commands without checking extra things - however it is somewhat complex to implement, because to just so use it, it would need to prevent commands if the referenced player is not the trusted one anymore. It would also make sense to somehow indicate trusted names differently in chat, so similar names don't get mixed up - this is a big cross-plugin issue, because it needs to rely on some API-thing that likely won't be built in, while plugins will take even more time to pop up.
- Making heavy use of clickables and hoverables: This could help clicking through things instead of remembering commands. While this is not a "full" solution, it can help a lot. Also filling in signs with a clickable/guided thing makes sense, to not mistype an account number. However it also has the problem that not all plugins do it, also there are multiple ways to do it.

 

It destroys everything!!!!!!
I like the names how it is now, i hope they add that you can change your name once or twice and not every day...

 

Well this is going to be a pain in the ass.

 

If that is how it works, then I'll be very happy .

 

O dear this is not good... This is one of the worst decisions Mojang has done so far.

 

It actually isn't, at all. It means that users can change their usernames, and for plugins a relatively small amount of work is required. The problem is that looking up players will require effort, but plenty of other games and engines (see Source Engine and SteamIDs) are working fine with it.

The best part is that maybe, just maybe, we can get some damn OpenID soon.

 

A Youtuber ive been watching for a while now has explained this very well (or atleast for me to understand)

 

Agreed is not a bad decision per se, however it causes a lot more work for a lot of people and likely kills off a good bit of much-used ingame-user-interfacing, not to mention it allows easier methods for trolling. Also i don't see how the examples of source engine and steam client relate to running CraftBukkit servers, despite somehow having to do with uuids. I see the big impact not so much with looking up uuids nor using those instead of player names, but with the user interfaces, plugin dependencies and cross-plugin compatibility all becoming more complicated and less trustable.

Seems comforting that people can't change their names with 1.7.6 yet, also that the transition is not instant .

 

Good to know, I hope you're also doing this (or will do this) when the player.dat files are renamed to uuid.dat
Also I think it's not too common that people need an offlineplayer with UUID who has never been on the server.

Heh, that was me (Redstone Sheep).
when you run 1.7.6-pre, white-list.txt is renamde to white-list.txt.converted (and won't be used anymore). The new whitelist is whitelist.json which has this format:

Code:

[
  {
    "uuid": "ae795aa8-6327-408e-92ab-25c8a59f3ba1",
    "name": "redstone_sheep"
  },
  {
    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",
    "name": "Notch"
  }
]

please note that simply changing the "name" key won't have any effect.
banned-players.json, banned-ips.json and ops.json have a similar layout.

There's also the file usercache.json which looks like this:

Code:

[
  {
    "name": "redstone_sheep",
    "uuid": "ae795aa8-6327-408e-92ab-25c8a59f3ba1",
    "expiresOn": "2014-05-03 20:29:36 +0200"
  },
  {
    "name": "Notch",
    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",
    "expiresOn": "2014-05-03 20:29:36 +0200"
  }
]

I assume this is used as a uuid-cache instead of requesting the username every time.
The "expiresOn" key seems to be 1 month ahead.
I take it that usernames can only be changed every 30 days (or more)

 

What will happen when name changing is allowed and a server is still on 1.7.x? I assume players could change their name and still play on older versions.
So there is no way to stay safe without updating plugins, not even by sticking with what is currently working. Once name changing is possible, all servers will need updated plugins.

This is a big hassle. Changing stored data from names to UUID isn't hard, but there has to be a lookup system for reading/writing names in game that converts both ways, which I'm sure will be possible.
And then there's also things like plugins that use names on signs, they all need to update when a name is changed.
I write all the plugins for my server and there is just so much to do and no sure way of doing it, it's overwhelming.

 

as a server owner i think it's safe to say that we've got our work cut out

 

1.7.6 will provide more support for using uuids, converting either way for online players won't be hard, however it hardly will reduce the hassle in terms of how to keep signs/commands/features going. Updating all signs on detecting a name change seems possible, but probably not an option concerning performance, so you're probably left with a token/code system instead - or you just have players use signs with names for not so important things and let them change the signs - what's important and if/how you use tokens is a question many server owners will have to tackle, though not all have the choice to code those themselves.

For offline players it will become more itchy. Adding friends to protection... can a uuid from a cache be used, do all commands have to be changed to asynchronous handling, because we now have to look up the uuids for yet unknown players?
I commented on the trust question in other posts... how will players be supported to know that a name still references the same player/buddy as usual, they will hardly learn uuids by heart, in addition it could be useful to be able to tell similar names from each other in terms of fencing off trolls, e.g. with a buddy system (MickeyMous3 is your friend. MickeyMouse was RoadRunn3r2 two days ago.). It would help a lot if players can only change their name once in a month or so.

I will start writing a plugin/component that just gathers all data (uuids, names, ...), stores them and keeps updating or just extending the data. The next step for me is a lock-down functionality, which can disallow players joining with known names but changed uuid - just to be able to run legacy plugins and to buy some time. Likely it won't need to prevent them joining but probably confine them to a special world (similar to preventing, but ok ...). Meanwhile i will keep thinking how to make commands and signs work. Likely i will decide for a token/short-id system, because i intended to add features like shared bank accounts and ... tokens to allow a group of certain people access to something, anyway. Clickables, Hoverables, commands to fill in arguments for commands ... hard to tell what next, some plugins i am using might die or take forever to update, or they are just unusable with their own special way of handling things, so i end up implementing almost all functionality myself, for which i could use buying a lot of extra time.

Actually i am glad that they give the modding community a little bit of time with a transition period and data-transforming before we are cut off with 1.8 - only thing i could use is some more statements on how reliable uuids will be from what point of time on, and if Mojang will provide some history for players whose uuids got changed for whatever reason, i.e. something like that web service that allows looking up entries with uuid and player name - just then with a sorting order and some statement about the reliability of that.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Will it also break servers/plugins that are running on 1.5.2?

 

Lol, thanks for the info...

 

Yes. This doesn't just affect new versions, but old ones as well because players can change their name which has always been hosted by Mojang. So servers running 1.5.2 will have the problem of not being able to properly track players if they change their name. There is no way to go back in time and fix that fact. To Mojang, what is in the past is in the past, they don't care much about 1.5.2. I know mod developers often don't update to the newer versions, they will pretty much be forced to at this point.

 

Is it planned to add Bukkit.getOnlinePlayer(UUID id) and Bukkit.getOfflinePlayer(UUID id) ?

 

Right now they're just recommending using a Mojang-offered solution of AccountsClient to get a UUID from Username.

But probably.