`auth.getPlayerInfo` does not automatically handle the `accessToken` of `header` after login

[ikexing]

Hello, when I use vapic.auth to authorize and then use getPlayerInfo, it does not require me to pass the Authorization in the header, and it also does not seem to automatically handle the accessToken obtained after logging in.

I need to manually implement a solution similar to the one below:

const parsedAuthResult = parseTokensFromUri(
  authResponse.response.parameters.uri
);

vapic.auth.getPlayerInfo({
  headers: {
    Authorization: `Bearer ${parsedAuthResult.accessToken}`,
  },
});

Is this the expected behavior? If not, could you consider changing the TS type so that users can have a clearer understanding of the current situation?

[Tanishq Manuja]

Yes, It was a design choice to make the clients ( auth, local, and remote ) and their scoped variables inherently separate. So one can run only auth client without using a remote client at all.

I agree there should be some indication to the user about the headers, I will think more whether it should be docs or type definitions.

For now, If you are using remote api client you can do something like this

vapic.auth.getPlayerInfo({
  headers: {
    Authorization: getAccessTokenHeader(vapic.remote.options.accessToken),
  },
});

And if you are only using auth api client, then what you have already coded in fine.

How are you logging in btw, I can give info accordingly?

[ikexing]

Thanks for your help, below is the code:

let authResponse;
if (mfcLogin) {
  authResponse =
    await vapic.auth.putMultiFactorAuthentication<ValorantAuthResponse>({
      data: {
        code: mfaCode,
        rememberDevice: remember,
        type: "multifactor",
      },
    });
  // retry logic
} else {
  authResponse = await vapic.auth.putAuthRequest<ValorantAuthResponse>({
    data: {
      remember,
      username,
      password,
      type: "auth",
      language: "en_US",
    },
  });
  // retry or check mfa logic
}

// finish login
const parsedAuthResult = parseTokensFromUri(
  authResponse.response.parameters.uri
);

vapic.auth.getPlayerInfo({
  headers: {
    Authorization: `Bearer ${parsedAuthResult.accessToken}`,
  },
});

From my understanding, using auth.getPlayerInfo in this context should eliminate the need for setting headers again.

Additionally, I'm curious about the auth.getCookieReauth, Is it necessary to handle cookies separately?

[Tanishq Manuja]

If you're doing something custom with the cookies then you need to handle those.

Btw looks like you're trying to do MFA auth, is there a reason for not using inbuilt providers ?

provideAuth() or provideAuthAutoRegion() implements the same logic iirc.

[ikexing]

Btw looks like you're trying to do MFA auth, is there a reason for not using inbuilt providers ?

I used legacy code that caused this issue. I manually implemented a simple code before discovering this library, and I will update it later.

---

About reauth, I noticed that the URL used for logging in is https://auth.riotgames.com/api/v1/authorization, while for reauth it's https://auth.riotgames.com/authorize.

According to the implementation I checked in the source code here, does this mean that I need to manually save the cookie?

Maybe I'm using it incorrectly, what do you think is the current best practice?

[Tanishq Manuja]

Answering your other query, why it doesn't auto set headers ?

Reason: I prefer a more functional approach to the clients. That means it will not store any state internally, which is the client only depends on the inputs.

Benefit of the approach:

Two instances with the same input produces the same output always hence are predictable and testable.

[Tanishq Manuja]

According to the implementation I checked in the source code here, does this mean that I need to manually save the cookie?

Maybe I'm using it incorrectly, what do you think is the current best practice?

Cookies need to be handled only if you need something like this:

• your programs starts
• does login using a couple of requests via username and password method
• this is will generate two main cookies namely asid and ssid
• your programs save cookies from auth api client to a file lets say cookies.json
• fetches other stuff as usual - like mmr etc
• program exits

---

• your program starts again
• read cookies from cookies.json
• login using cookie reauth without sending username and password
• fetched other stuff as usual - like mmr etc

[ikexing]

Got it, thanks a lot for your help and patience!