mojira.dev

Florian Wesch

Assigned

No issues.

Reported

No issues.

Comments

@mcmonkey, it only works like that in 1.7. In 1.8, spawning NPC won't be possible any longer unless you have the non-expired texture blob. If you spawn NPCs with an expire texture blob, all clients that receive the SpawnPlayer packet will disconnect.

https://miners-movies.com/ programmer here. I'm affected by this as 1.8 will probably prevent my service from showing you recordings using the vanilla Minecraft client, therefore totally ruining the experience. I also suggest removing the timestamp that prevents using the skin after 24h.

According to Grum, old skins won't be deleted ever once uploaded to the server. So the combination of UUID and skin can be frozen in time without becoming invalid. Ignoring the expiration date would then only allow server owners to assign you a previous skin you used (if you have ever joined the server using that skin or acquired the hasJoined texture blob in any other way). It won't allow server owners to assign you skins you never used. On the other hand it would also allow server owners to spawn NPCs of players, provided they have their texture blob. Which might or might not be something mojang wants to prevent. :-\
Another solution (in my case) might be to have a Minecraft Client option that toggles whether the client checks the timestamp or not (Somewhere next to the "Allow colors in chat" maybe? "Show expired skins" (any other suggestion?)).

Just some information about this issue. In 1.7, links are not parsed inside normal text sent by the server. To have clickable links, the server has to sent them in special way so they can be clicked on the client. So instead of sending:

{"text": "http://link"}

the server needs to send

{"text": "http://link", "clickEvent": {"action": "open_url", "value": "http://link"}}

(See https://gist.github.com/thinkofdeath/e882ce057ed83bac0a1c for more information about this)

I'm not sure this will be changed. But it should be easy to have a bukkit plugin in the future that does this.

This bug is fixed now. The problem was that I hit the client-/accessToken limit. Once that happened the auth server was supposed to remove the oldest token. Instead it removed the newest token which resulted in the observed behavior. This bug is fixed now. Everything works as expected now.

Maybe this is an easy way to reproduce this problem:

  • Log in to Minecraft using the normal launcher

  • Connect to any server that requires authentication -> works

  • Disconnect from that server

  • Do an authenticate request to authserver.mojang.com:

    curl https://authserver.mojang.com/authenticate --data-binary '{"username":"XXXXXXX","password": "XXXXXX", "clientToken": "01234567890123456789012345678901", "agent":{"name":"Minecraft","version":1}}' -H "Content-Type: application/json"

    The username in my case is my converted mojang account, so I'm using my email address. Note that I'm sending a (made up) clientToken. This, according to http://wiki.vg/Authentication, shouldn't invalidate any other accessTokens.

  • The authenticate call succeeds:

    {"accessToken":"e866XXXX","clientToken":"0123...","selectedProfile":{"id":"035XXX","name":"dividuum"},"availableProfiles":[{"id":"035XXX","name":"dividuum"}]}

  • In the open Mincraft Client, try to connect to the same server as previously -> Bad Login (why?)

  • Close Minecraft ("Quit Game")

  • Restart the Launcher. It will say "You're already logged in as <your username> in another profile".

  • Log back in.

  • In the Development Console will be this messages:

    Refresh complete.
Loaded 1 profile(s); selected 'dividuum'
Refreshing auth...
Logging in with access token
net.minecraft.launcher.authentication.exceptions.InvalidCredentialsException: Invalid token.
	at net.minecraft.launcher.authentication.yggdrasil.YggdrasilAuthenticationService.makeRequest(YggdrasilAuthenticationService.java:118)
        ....
Delta time to compare resources: 457 ms 
Download job 'Resources' skipped as there are no files to download
Job 'Resources' finished successfully
Logging in with username & password

This leads to the following questions:

  • This looks like the previous accessToken got invalidated by the authenticate request. Is that correct?

  • How many accessToken can be active at the same time for a user? Is this limited somehow?

  • What does the "You're already logged in ..." error message mean? How is being logged in determined?

  • Do I have to signout somehow, so other accessTokens can be reused?

  • Are there any requirements for a clientToken (length, etc..)?

  • I only have a converted mojang account. Maybe it works for non-converted accounts?

  • Is this the intended behavior?


Other observations:

  • Omitting the agent field works and doesn't seem to invalidate the existing session but provides no profile id information, so it's not possible to create a session token which is needed for login.

Thanks for any feedback.