[MCL-7178] Failed to Login: Bad login on old versions Created: 06/May/17  Updated: 01/Jul/18  Resolved: 26/Jun/18

Status: Resolved
Project: Minecraft Launcher
Component/s: None
Affects Version/s: 2.0.806 (Windows), 2.0.895 (Windows), 2.0.934 (Windows)
Fix Version/s: 2.1.1216 (Windows) / 2.1.1217 (Mac OS) / 2.1.1218 (Linux)

Type: Bug
Reporter: the1kingsam Assignee: [Mojang] Petr Mrázek
Resolution: Fixed Votes: 5
Labels: None

Issue Links:
is duplicated by MCL-6017 "Failed to login: Bad Login" on local... Resolved
is duplicated by MCL-6223 Bad Login on older versions of minecraft Resolved
relates to MCL-7282 Minecraft Launcher fails to pass Sess... Resolved
Confirmation Status: Unconfirmed


If you try to create a local server for an old version of Minecraft, anyone that logs in with receive Failed to Login: Bad Login.

This is a launcher bug because
1) Old servers worked on the previous (unused) launcher
2) The launcher gives the user access to old versions

Easiest way to test is to run a 1.11 server and login to localhost and it will work fine
Then run a 1.2.5 server and try to use localhost (while playing version 1.2.5) and you will get the bad login error.

Since this is a bug about "Old Versions" I can see why it might be dismissed and ignored but keep in mind that these servers DID work on the previous launcher and every one of these versions is available to play in the current launcher, so servers for each version should work properly and multiplayer should not be more limited than singleplayer.

Comment by [Mod] Pokechu22 [ 07/May/17 ]

To verify, it does work if you launch the game with the java-based launcher (which you can still get from the alternative download page); it just doesn't work on the native launcher? If so, that is a very weird, specific bug since both of them should launch the game the same way - if they don't, it definitely qualifies as an MCL bug (just like bugs with modded profiles and profile inheritance)

Comment by the1kingsam [ 07/May/17 ]

Correct. After downloading the Java launcher and testing this, I CAN CONFIRM that the problem only occurs if the user is attempting to join the server from the new native launcher. If you use the old java launcher you can join the server but if you use the new native launcher you will get Failed to Login: Bad Login.

Comment by Noah Christian Oseguera [ 09/May/17 ]

Hey. It wont let me login to my Mojang account and it just says invalid password or username. But I've reset them both so anyone have an idea? I cant login via laucher or via minecraft.net Can you awesome people help?

Comment by Michael Steenbeek [ 19/May/17 ]

I can confirm that this bug also occurs on macOS (Sierra) and Linux (Ubuntu 16.04 and 17.04). I run a Minecraft 1.6.4 server. As with the OP, using the old Java-based launcher does work, but the current launcher fails with 'Bad login'.

Comment by Stuart Walton [ 25/May/17 ]

I believe that this is caused by the player's authentication Session ID not being passed to the Minecraft Client by the launcher.

I created a ticket for it - MCL-7282

Other Duplicates

Comment by Stuart Walton [ 30/May/17 ]

Tested MCL 2.0.895 and it is still an issue.

Comment by Stuart Walton [ 15/Jun/17 ]

Tested MCL 2.0.934 and it is still an issue.

Comment by Stuart Walton [ 30/Jul/17 ]

For each version of Minecraft there's a version json file. Inside there's a minecraftArguments key that tells the launcher what arguments to pass to the client jar:

Here's the one from 1.8.json, a version that works:

"minecraftArguments": "--username ${auth_player_name} --version ${version_name} --gameDir ${game_directory} --assetsDir ${assets_root} --assetIndex ${assets_index_name} --uuid ${auth_uuid} --accessToken ${auth_access_token} --userProperties ${user_properties} --userType ${user_type}"

Here's the one from 1.6.4.json:

"--username ${auth_player_name} --session ${auth_session} --version ${version_name} --gameDir ${game_directory} --assetsDir ${game_assets}"

1.6.4 uses the argument session and is passed the variable auth_session.
1.8 uses arguments uuid and accessToken and is passed the variables auth_uuid and auth_access_token respectively.

I suspect that the auth_session variable is not available in the new launcher. I tried editing the 1.6.4.json so that it passes the argument:

--session ${auth_uuid}:${auth_access_token}

but the launcher is pretty strict about the files not being messed with (for good reason) and re-downloads it if its hash is wrong.

The fix for this issue may be as simple as making sure that the auth_session variable is available for building the java arguments string.

Comment by [Mod] Pokechu22 [ 30/Jul/17 ]

Thanks for the analysis!

but the launcher is pretty strict about the files not being messed with (for good reason) and re-downloads it if its hash is wrong.

That's not entirely accurate; it does re-download it for known versions, but you can freely modify your own versions. So if you want to test, copy the version folder (e.g. 1.6.4) and name the new copy something different (e.g. 1.6.4_MCL-7178). Then also rename the .json and .jar files in there to match the new name. Finally, open the JSON, and change "id" to match the name. You're then free to change the JSON further. (If you're going to modify the JAR, you also need to remove the root downloads block; this is needed for old-style modding but I won't detail it).

In any case: I can confirm that the new session ID is correctly read by the game (as seen in the client output), but it still doesn't seem to login successfully.

Comment by [Mod] Pokechu22 [ 30/Jul/17 ]

Got it! You correctly identified the cause, but your format for the tokens was wrong; it should be this (prefixed with token: and with the session ID before the UUID):

--session token:${auth_access_token}:${auth_uuid}

I can confirm that that works fine. (Probably this should be fixed by implementing ${auth_session} in the new launcher)

Comment by Michael Steenbeek [ 14/Aug/17 ]

Thanks, Stuart and Pokechu22! I can confirm that this workaround works on Linux, using version 2.0.391-dev-linux. Hopefully a developer can fix this properly soon.

Generated at Fri Dec 14 02:03:24 CST 2018 using Jira 7.11.2#711002-sha1:fdc329dee91471a641faabfe39b5ff8c0a5b3f66.