Jacob Crofts
Assigned
Reported
Comments
> there shouldn't be any database or other userdata storage which is solely based on names in 2022
The vanilla Minecraft server ban list is based solely on names and not UUIDs (I agree that it shouldn't be). So are the data storage structures of multiple legacy ban/mute plugins I've inspected.
> Edit: Also projects exist to use namemc as api like https://github.com/jaqobb/namemc-api so I really don't see the problem here.
NameMC now uses a CAPTCHA to protect their site from automated traffic, so we cannot rely upon this and similar projects
Do we have the ability to bump this to maximum priority? This feature has been broken in production for months and has no workarounds short of scraping data from third party websites. We would appreciate confirmation that this is on the roadmap.
Thanks to whoever added a note on the API wiki page that this feature is broken.
I am also impacted by this. I accidentally filed a duplicate ticket, but it has a concrete example with curl that might be helpful: WEB-3502. It looks like Mojang's API is ignoring the "at" parameter entirely.
I agree that the profile name history endpoint is not sufficient, as there are use cases in which the player UUID is not known.
In my case, I am writing a plugin that will migrate incomplete data generated by popular ban plugins (e.g. AdvancedBan) to other plugins. Some legacy plugins store only the username of the moderator that issued a punishment, whereas others include (and require) the UUID. So I need to be able to know the UUID of a player, given the player's username and the time at which the player was known to have that username.
I apologize; I was hunting around and just realized that this is a duplicate of WEB-3367. Maybe the example I provided will be useful for pinning down exactly what is broken.
This is an issue for me as well. Video settings are default to my knowledge, allocated 2G RAM rather than 1, no client mods.
This issue should be closed, as Mojang no longer supports player username history lookups, making it illogical to support the username-at-time endpoint. Their lack of communication with regard to this ticket makes sense given that deprecation was planned but unannounced.