MicrosoftAuthenticator login functions doesn't seem to actually log in the player

[theavgeekbee]

Describe the bug When running any login method in MicrosoftAuthenticator, the client doesn't seem to log in. I verified this by running the loginWithCredentials method with my own credentials, but no exception was thrown. When logging into singleplayer, I was still on the default Fabric profile of "Player###" and multiplayer yielded "Invalid Session".

To Reproduce Steps to reproduce the behavior:

1. In FabricMC, set up OpenAuth in Gradle normally.
2. In the startup code, I put

   MicrosoftAuthenticator auth = new MicrosoftAuthenticator();
   try {
   MicrosoftAuthResult res = authenticator.loginWithCredentials("[email redacted]", password);
   MinecraftProfile prof = res.getProfile();
   System.out.println("Logged in as " + prof.getName() + " (" + prof.getId() + ")");
   } catch (MicrosoftAuthenticationException e) {
   e.printStackTrace();
   }

3. I started FabricMC
4. I saw "Logged in as ...", but in singleplayer, I got the default FabricMC username, and when I tried joining a server, I got "Invalid Session".

Expected behavior I expected OpenAuth to actually set the session.

Desktop (please complete the following information, if Self-Hosted):

• OS: Windows
• Java version 17.0.9-termium
• Version: Latest (1.6.1?)

Additional context I found a solution to this problem by manually setting a session. In my alt manager class, I created the function login(), which logs in the player.

public static Session session;
public static void login() {
        File secret = new File(".secret");
        String password;
        try {
            password = Files.readString(secret.toPath());
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
        try {
            MicrosoftAuthResult res = authenticator.loginWithCredentials("[email redacted]", password);
            MinecraftProfile prof = res.getProfile();

            session = new Session(
                    prof.getName(),
                    getFormattedUUID(prof.getId()),
                    res.getAccessToken(),
                    Optional.empty(),
                    Optional.empty(),
                    Session.AccountType.MSA
            );
            System.out.println("Logged in as " + prof.getName() + " (" + prof.getId() + ")");
        } catch (MicrosoftAuthenticationException e) {
            throw new RuntimeException(e);
        }
    }

Then, I created a mixin:

@Mixin(MinecraftClient.class)
public class MinecraftClientMixin {
    @Inject(at = @At("HEAD"), method = "getSession()Lnet/minecraft/client/session/Session;", cancellable = true)
    public void getSession(CallbackInfoReturnable<Session> cir) {
        if (AltManager.session != null)
            cir.setReturnValue(AltManager.session);
    }
}

This solved my problem, except the skins don't load. This is probably due to the missing clientId and xuid fields that I set to Optional.empty() in this code. I'm not sure yet, but I think OpenAuth has these fields in the code. I hope that this could be implemented in the future.

[shaivilp]

Quick question the account you are trying to login to does it have a minecraft username set?

[theavgeekbee]

Yes, I logged in to my main account.

[shaivilp]

Weird was just wondering since i made a pr request to add a new function that supports accounts without a name set

[ghost]

Necro but I don't care:

It's a library to get a session/access token from an account and not a library to automatically set the session..that's not what it's supposed to do.

[theavgeekbee]

Necro but I don't care:

It's a library to get a session/access token from an account and not a library to automatically set the session..that's not what it's supposed to do.

The Readme:

The phrase "LOGGED IN" implies that the user was LOGGED INTO THE ACCOUNT. You are correct, the current state of the library is to get the access token for an account. It does not set the session yet, and should be indicated as such in the README. The phrase "Logged in..." in the README is misleading because there is no indication that the user needs to set the session themselves.