Uploaded image for project: 'Mojang Web Services'
  1. Mojang Web Services
  2. WEB-3502

Username -> UUID at time endpoint ignoring "at" query parameter

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Normal
    • Resolution: Duplicate
    • None
    • None

    Description

      DUPLICATE – see comments

      The API endpoint for determining a player's UUID given a username and timestamp (documented here) is ignoring the "at" parameter and only ever returning the current player with that username.

      To demonstrate, here is a player that changed their name twice:

      ➜ curl "https://api.mojang.com/user/profiles/71a75aaae2a34938850dc97c07507d97/names" | jq
      
      [
        {
          "name": "HowdyDonut"
        },
        {
          "name": "LoopyKazoo",
          "changedToAt": 1575342738000
        },
        {
          "name": "HowdyDonut",
          "changedToAt": 1602456240000
        }
      ]
      

       

      We would then expect the following results when calling the username/time -> UUID endpoint (note that timestamps are converted from epoch millis to seconds, as required):

      • LoopyKazoo, 1575342738 => 200 / OK
      • HowdyDonut, 1575342738 => 204 / NOT FOUND

      However, instead, we get the following results:

      • LoopyKazoo, 1575342738 => 204 / NOT FOUND
      • HowdyDonut, 1575342738 => 200 / OK

       

      ➜ curl "https://api.mojang.com/users/profiles/minecraft/LoopyKazoo?at=1575342738" | jq
      
      # (no response body)
      
      ➜ curl "https://api.mojang.com/users/profiles/minecraft/HowdyDonut?at=1575342738"
      
      {
        "name": "HowdyDonut",
        "id": "71a75aaae2a34938850dc97c07507d97"
      }

       

      Furthermore, I have noticed that I can pass nonsense input via the "at" parameter without triggering a 400 / BAD REQUEST.

      ➜ curl "https://api.mojang.com/users/profiles/minecraft/HowdyDonut?at=ayy-lmao" | jq
      
      {
        "name": "HowdyDonut",
        "id": "71a75aaae2a34938850dc97c07507d97"
      }
      

       

      So it seems likely that the API is ignoring the "at" query parameter. That would explain why the param is not validated and the endpoint only ever returns the current UUID for the username at hand.

       

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              JacobCrofts Jacob Crofts
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: