Convert UUID -> Username #2
Comments
|
On vacation, will answer soon. 🐨 |
|
Thanks @mollstam , would be much appreciated! |
|
Any updates on this @mollstam? We need this as well. |
|
Haven't worked on it yet, schedule pretty crammed right now 😱 |
|
Thanks for the update @mollstam |
|
@mollstam Pls work on a fix for this! I rly need this fixed to do my project :3 |
|
@ayantwan If you want it that bad, at least take the time to spell it correctly |
|
@iKeirNez pls chill out bro... itz the inturnet u dnt need 2 spell everything rite this is n't a essay .-. |
|
@jjacobson I like ur pic can u send me the P.N.G. so i can photoshop it as my git pic? |
|
@ayantwan this is the wrong place for that, me and everyone else gets a mail just because you don't right click the image yourself. But here is the picture so no more useless comments are required. Don't thank me. |
|
This would be very useful to have... |
|
Its been three months since your last comment, @mollstam. The README says it "allows player name <-> id resolution" but it currently only allows player name -> id resolution. I'd say this is a bug, not an enhancement. Minecraft proper's updates are bringing us closer to having changeable screen names and those of us who do off-server development will need something to get the names with so they don't just change out from under us. |
|
@navarr It's also needed for server/plugin development, depending on what you do. |
|
Fixed. |
|
Nice... @grum you jerk :p |
|
This issue was not about the typo in the readme, but about the lack of the feature that is strongly needed to make use of the new UUIDs when working with externally stored player-names. Given that this simple fix has not been provided within the last 4 months and what we know about Mojang's way of doing things, I just can prepare (both as a developer and server-admin) for the chaos that will unfold once you choose to allow name changes. |
|
So for which "usecase" that we aren't having do you claim this is "strongly needed" ? |
|
The fact that you can only uniquely identify Minecraft players by UUID and that there's no way to get their username without forcing them to login? I currently run a website that requires users to login with their Mojang credentials on my website (because there's no OpenID or OAuth way to do so yet), which is when I can grab their Username and UUID, toss their credentials and make them create a password. Without the ability to update the username cache from the UUID, they will have to constantly log in using Mojang credentials in order to verify what their username is. This library appeared like the intent was resolution back and forth - having username -> uuid is great for updating legacy datastores to account for it, but in no way does it let us update those with what the user's name is. Without that functionality it's a complete disaster for network operators and web developers who rely on usernames. |
|
Ah so you are one of those malicious Mojang account harvesting sites (or have no way to prove you are not and still try to get people to log in using our credentials). I do not see why we should care for things that base their system on usernames, migrate to use UUIDs and your problem goes away. As you have already said, you can migrate using the tools we've provided. |
|
Thank you for assuming the worst about me. I just run a guild and need to verify people own the account they say they do. All of my code is open source and hosted under this username. We can, and are migrating to use UUIDs but that doesn't solve the problem of figuring out what the user's username is (for display purposes at least). UUID to username is so that we can periodically update our username cache without requiring the user to go through Mojang authentication. I could understand a "this will come, but it's not on our roadmap" but a "there's no need for this functionality" is shooting the community in the foot. |
|
This would indeed be useful when storing UUID and you want to get the current username.
|
|
Do verification of people after they log onto a server and your problem is solved. Store the 'last known username' if you feel the need to somehow show their username. Why do you think we want people to 'on a schedule' go look up the 'real' name for a UUID? Why does this sort of accuracy matter? You know the persons name if they log in, that name is good enough until it changes right? |
|
Alright, let's look at my use case again, shall we. Ignoring the "users have to give their mojang credentials to register" bit, I run a Guild website for a pretty active server network. These users never connect to a Minecraft server I own through the normal perspective. Whether or not Mojang provided a form of secure authentication, the following problem could still exist:
@mollstram's comment shows he was going to add this feature, which would solve this problem. |
|
I'm not sure why we would need to implement something so you can do something that has nothing to do with the actual game. Also the only usage such service will get is 'lets see if we are up2date'-spam. Your problem would be solved if you'd collect the names through a server, mark someone as 'having to log into your server' when someone else comes by with an identical username. |
|
Because without it any service, forum, network, or website that works based off a user's Minecraft identity can not reliably state who a user is. If you're worried about spam, give it a rate limit. Well behaved servers (that would be well behaved because that's the only way to get the data) will issue a single request for updates. Best behaved servers will do that only for users that need to be updated. I'm a big fan of Minecraft-proper, but so much that does or can benefit the community around the game, increase sales, and increase active users relies on being able to tell who a user is. In the above situation, any stats pages about the user wouldn't really know who he is. No user would be able to private message them (without terrible workarounds like giving them some form of temporary name). There isn't a good reason not to include what should be an hour or two at most adjustment (if your internal architecture is sane) to return profile objects by ID instead of by Minecraft username. |
|
An hour or two to build, a lifetime of upkeep/maintenance. Unless you have been in-game, there is no such thing as a Minecraft Identity. You seem to be trying to work around that and I do not see why. A user would be able to leave a private message for the UUID of the user. Stats pages for people that have been offline long enough, renamed themselves and then someone else has taken their name, logged in and basically 'un-named'-them can simply mark that user with "name is unknown". Apparently the player is not playing anymore, why would having the 'current name' on their stats matter this greatly? There still seems to be very little justification for overcomplicating the current system. |
|
True regarding maintenance. But it shouldn't be too much more than the current system, unless you're planning to phase it out. Again, I'm approaching all of this from an extra-server community. A guild based around a game on a server. There are various communities regarding Minecraft that would benefit from the ability to determine a Minecrafter's identity without a server they constantly log on to. Any sort of distributed ban system, for example. Any sort of skin website, particularly for more famous identities (Notch, HighlifeTTU, SkythekidRS, etc.). Any sort of forum surrounding the game or sub-games (but do not run the game themself). Without that API, all of these are essentially doomed in terms of information maintenance. Not to mention things like Enjin and other gamer forum-esque places that want to identify who you are in game. The benefits far outweigh the small cost of maintenance on this type of API. |
|
My usecase for this would be if for example I store players points and the key is the players uuid. But what if we want to display this info to another player? We don't want to display a uuid but rather their display name. As a current workaround we store players last known display name with their uuid. I'd do this anyway even if this feature was implemented to reduce load on your side. However it would be nice to update their display name without them logging in. |
|
Yes, we'll be storing the 'LastKnownUserAs' as well. Why does it matter what the current name is? The guy is banned, for 'history' it actually makes more sense to record the name at the moment you banned him, how else are you going to remember who this person was when you later read the ban-list? |
Then give us a way to go from UUID > username? What happens if player B changes his name, then player A changes his name to what player B had? That will cause a ton of problems, because until player B logs back in with his new name, there will be two players with the same "last known name" |
|
What happens is that apparently the old player isn't playing on your server anymore, so he'll simply not have a name anymore. And as he's not playing on your server anymore and changed his name, why would you need to be able to accurately display it? :) |
|
Said player currently isn't connecting because he was banned. Player appeals through a website-based appeals system. We need to know both what his username was (up to us to keep history) so we know what he did and what his username currently is (impossible) so that we know who to keep an eye on. |
|
Your system can simply update the name after you unban him and he logs in, that way you know who to keep an eye on. |
|
So essentially, instead of telling the admins who the user will be, we have to notify the admins after the fact about that this new user XMcX is in fact YMan384. Which is an absolute shit workaround for a problem that would be an easy fix. |
|
Wait, I just gave you a solution that is perfectly sane to use (you could even automate this notification). Arguably less work than for us to create and maintain UUID->name forever. |
What if they just dont log in for a few days after changing their name? Great to know how backwards mojang does everything. |
|
You're not giving me solutions, you're giving me excuses as to why SELECT username FROM minecraft_accounts WHERE uuid=:parameter or, god forbid SELECT username FROM minecraft_accounts LEFT JOIN mojang_accounts on minecraft_accounts.id=mojang_accounts.id WHERE mojang_accounts.uuid = :parameter Is too much trouble. AFTER @mollstam initially said that such an API would be provided for no real rhyme or reason as to why the sudden change except that maybe privacy issues, while completely ignoring or proposing absolute shit workarounds to every valid reason why we need this. It's gotten to the point that I've completely lost faith in any hope of sanity to come from this discussion, and your viewpoint on non-servers makes it abundantly clear I shouldn't even bother asking for some form of non-session user authentication of accounts because you don't have a care in the world for the active and adoring community surrounding your game. |
|
There is absolutely no reason you cannot wait until a user logs in until you can detect his name has changed. You don't seem to demand that we inform all servers someone has ever played on when they change their name in real time. Why would it matter if you 'know' it before he logs in? |
|
|
You forget, it is not stating that it is doing this now :) Aka: problem solved (because it doesn't exist). |
|
That doesn't solve the problem. That just points out that I'm lucky enough never to have had to deal with it yet, because the ability to change names has been relegated to a very small amount of people. And a complete lack of transparency as to what requirements will surround the ability that will come with 1.8 (only once? once per 24 hours? any time you want to? after documentation? no documentation?) is completely terrifying. |
|
We don't know yet; we haven't discussed it yet. We're simply stating that we're not activating it before the code get's updated at least one 'version' ago. (aka: update in 1.7.6, first possible renaming after 1.8, can be later!) |
|
I'm not sure why Mojang thinks it is less effort to spend all day making up excuses and hurting the community, vs. exposing a UUID->Nickname mapping API. I mean, think about it. How much time has @grum spent on this ticket explaining why the API consumers are wrong, when it would literally take 10 minutes to write the code that makes everybody happy? At some point you just have to eat the sunk cost and deal with the actual issue, because 5 more days of arguing from now, that will still be the correct solution to the problem. |
|
Good to know Fishbans will just have to stop displaying any relevant username and just give an ugly UUID. Good to see that we are protecting the community. /s |
|
The implication that moving to a unique identifier for players is somehow going to prevent all plugins from ever indicating what someone's name is or was, is absurd. Would it be helpful if Mojang exposed an API that, say gave JSON data about a UUID - of course. For local performance reasons though, calling it all the time would be a waste of time. I'm the author of the aforementioned Prism - we obviously have to associate a username with an event - showing the UUID is like remembering users by their IP - it clearly won't happen. I honestly haven't thought much about how we'll handle it once the UUID system is properly exposed by bukkit, but it's a matter of tracking a UUID and a list of all known usernames. Maybe we'll display the name they had at the time, or the name they're known by now. Or we'll allow that to be configured. As a server owner, it wouldn't be complex to see a list of all "known names" for a specific id. In our case, we already display lists of all users connected to a single IP address to staff, so this is no different. |
|
I agree that for the use cases I had in mind a per-server solution that gets the last known username might be suited better. A fallback that provides UUID -> name conversion might be needed nevertheless, e.g. for displaying informations about users who did not login (say, when displaying a whitelist on the website). Since @grum has made very clear that Mojang has no intention of providing the later, you better make good dam sure that the last known username cache is fully implemented with 1.7.6 so bukkit and others can make use of this feature. Without it we simply cannot use UUIDs when the data needs to be displayed - unless every mod/plugin caches the last known username themselves which might be a reasonable option for loggers such as Prism, but not for plugins that have completely different purposes. Besides it would have been very nice to have this information 4 months ago or even better to have the last known username cache implemented together with UUIDs in 1.7.2. |
|
Hey guys, You'll be expected to store your own last-known-as cache when you convert your database from names to UUIDs, as the game will do in 1.7.6. We do not have a bulk lookup service right now, we may add one in the future but it's not a high priority. In the mean time, if you absolutely need to know information on a UUID to a name you may use a single lookup service here (bonus points: it'll give you skin/cloak info too). The only thing you need this for that I can tell is for display purposes to communicate to users, which we need it for too. However, going the super expensive route of trying to mirror our database by keep asking "who is 61699b2ed3274a019f1e0ea8c3f06bc6?" is bad (even if you had bulk lookup), from both technical and user experience side of things. Technically, it's bad because even without a rate limit, bandwidth constraints, computing resources and all that aside you'd still not be able to keep up with theoretical changes that could happen. User experience, if a guy called "Tony" changes their name to "Samantha", the user likely won't know who "Samantha" is, they only knew the guy as "Tony" at a certain date/time. This is where a last-known as lookup comes in and saves the day :D |
|
@Dinnerbone Thanks for clearing this up! |
|
Just to clarify this, usernames can only be 'owned' by one person at the time right? So if I have CraftThatB, and someone tries to change to my name, they won't be able, right? |
|
@Dinnerbone the lookup service you mentioned in your post is not working for other UUIDs then yours (I used my UUID in the link). When will that be fully functional? Or was it and is bugged now? |
|
The ID you linked does not exist for any valid user in Minecraft. |
|
Yeah, I noticed that too a second ago. Thanks for your help nonetheless. |
|
@Dinnerbone doesn't sessionserver.mojang.com destroy that users session if they are online? |
|
the last player name that is used will be connected to the uuid that is specified if a used joins with a different username but the uuid is the same then the player name is changed automatically while the uuid stays the same... at least that is how i see some permissions plugins working with bukkit... loads of developers of plugins already have such things implemented and is not hard to check uuid versus username... instead of using the players username to whitelist/greylist them use their uuid as those never change and will be more compatible in the future... PS: don't know how much of this makes sense as it is very early in the morning for me. |
|
@grum If you guys implemented OAuth ("Login with Mojang") which was directly mentioned in the post you were replying to, then nobody would have any reason to run a "Minecraft account harvesting website." There are lots of sites that are built around Mojang, and so far we have to use this rudimentary API to try to keep in-game identities up to date.. and we're not even sure if it's really them or not without asking for their password (which, by the way, I have chosen not to do and just trust the username because doing so makes me uncomfortable). And yes, I am storing UUIDs as the primary data and using that to do username resolution so that it will work with the forthcoming username change system. These sites are not based on a Minecraft server, so doing in-game verification isn't a proper solution. Also last I heard the Mojang account system is OAuth-like, so all that needs implementing is a way to approve or deny API access requests from Mojang's website. |
|
Just wondering about an update to this. I'd quite like it for logging purposes on a few administration plugins. |
So currently we can convert a Username -> UUID but as far as I'm aware you can't convert UUID -> Username. This feature is very much needed. Thanks Mojang for all your work so far!
The text was updated successfully, but these errors were encountered: