OAuth2 queues (#3185)

[sand rock]

With #3185 the rest manager is going to be able to correctly handle all the ratelimits (edge cases apart, hopefully there aren't tho) for bearer tokens without too many issues.

Since we need to inform the queues to change the authentication of the scheduled request (at least for my current implementation) there is the need to access the queue objects, but when the rest manager is proxied we need to send an HTTP request, the rest manager does have the informations it needs to send that request, since this could be an options of the proxy object under the CreateRestManager type, do we want to add a default value? if so, to what?

for reference: for my local testing i'm using /discordeno/token-update with a JSON body like this: { "oldToken": "...", "newToken": "..." } that then calls the rest.updateTokenQueues with those tokens

[sand rock]

for context, this is my implementation of the /discordeno/token-update endpoint:

app.post("/discordeno/token-update", async (req, res) => {
    const body = JSON.parse(req.body as string) as Record<string, string>;
    const oldToken = body["oldToken"];
    const newToken = body["newToken"];

    if (!oldToken || !newToken) {
        res.status(400);
        return { };
    }

    manager.updateTokenQueues(oldToken, newToken);

    res.status(200);
    return {};
});

It does miss the authentication control, the reason is really simple: it would complicate my testing for no benefit

the endpoint is implemented using fastify

[granite topaz]

What token are we updating?

[sand rock]

the bearer token after a refresh

[granite topaz]

Why does it get stored?

[sand rock]

wdym by stored

[granite topaz]

Like why it gets stored inside rest object in the first place

[sand rock]

the queue need to be aware of what token they are using for the request so they know what key they have in the rest manager under the queue mapping

the queues are stored like this in the manager: Bot <token><url> / Bearer <token><url> / Basic <token><url>

this applies to Bot and Basic too so it does support multi bot token, it would be extra work doing it only for bearer

(yes, i tested it and it seems to be working)

[granite topaz]

What does this queue contain exactly?

Like the ratelimit infos or so?

[sand rock]

it works the same way as the v19 queue

so it handle the ratelimit basically yes

the manger sends the requests to the queue and the queue keeps track of the ratelimit delays with the help of the parsing the headers of request by the rest manager and sends requests when there would not cause a 429

[granite topaz]

I see

And this also handles removal of them too right? After time of the bucket expires or so

Do bearer tokens even have individual ratelimits in the first place btw?

[sand rock]

they have individual user scoped ratelimit from what i tested

by the removal of them you are talking about the queue? yes

after 60s the queue is not used it gets dereferenced and the GC eventually will collect it

[granite topaz]

idk about ratelimits much tbh but ig it could be different per bearer but you also tested with the regenrated token and made sure the same ratelimit bucket carries over right?

[sand rock]

for my testing of this updateTokenQueues function i'm doing 3 requests to get the user guilds and after 1 i refresh the tokens and add another 3 on top, so 5 with the new token overrall and 1 with the old one

and i don't get any 401 or 429 in the processes

btw the entire job of updateTokenQueues is to update the queue to use the new token

[granite topaz]

i mean are you sure the ratelimits doesnt reset when you regen token

[sand rock]

yes i tried

discord carries over the ratelimit with a regen

(https://github.com/discordeno/discordeno/issues/3165) if you want to test for yourself just use this code: ```js
import { createRestManager } from "@discordeno/rest";

const token = "<bot token>";
const secret = "<client secret for the OAuth2 exchange>";
const id = "<your bot id>"
const code = "<the code given by an oauth2 code exchange flow>"

const manager = createRestManager({
token: dsToken,
});

const token = await manager.exchangeToken(id, secret, {
grantType: "authorization_code",
redirectUri: "http://example.com",
code,
});

await manager.getGuilds(token.accessToken);

const newToken = await manager.exchangeToken(id, secret, {
grantType: "refresh_token",
refreshToken: token.refreshToken,
accessToken: token.accessToken,
});

await manager.getGuilds(newToken.accessToken);

*for the code just create a oauth2 link that has the guild scope and gives you the code*

this is what you get btw

btw off topic, it would be an exploit of the ratelimit

the /oauth2/token or whatever the url is doesn't have ratelimit at all from what i tested (doesn't include the headers)

going back to the initial question, do you have another suggestion for the url?

thinking on it /discordeno/refresh-bearer-token might be a better alternative

[granite topaz]

Isn't this just for testing

update-bearer-token imo is good

[sand rock]

by this you are referring to what?

[granite topaz]

this

[sand rock]

then what do you mean by just for testing

[granite topaz]

isnt this just for your testing or something

or where exactly are you adding this endpoint

[sand rock]

the rest proxy needs this endpoint

[granite topaz]

i would say this should go into user's implementation

you're gonna be creating a webserver just for a single endpoint

[sand rock]

what?

dd just checks if you are proxying the requests to a rest proxy and if you do (and proxy all the discord requests too) then sends that http request to the proxy

if you aren't setting proxy.baseUrl in the restManager then the updateTokenQueues works on the in-memory queues and ratelimit paths

that endpoint needs to be part of the rest proxy, not a single endpoint

[granite topaz]

and youre talking about implementing them yourself into the rest proxy arent you?

[sand rock]

i don't get what you are saying

the url would be a thing that you need to for a rest proxy to handle OAuth2 requests thats all

like how you need to add the required stuff to handle application/x-www-form-urlencoded or else for example fastify will just give you an 500 (don't actually remember what it gives you tbf)

we could set an option under the proxy settings for the restManager to change this url (think about this way later then i should lol, aka 5 minutes ago)

[granite topaz]

im asking where is this endpoint gonna be in

is it from dd itself

[sand rock]

dd only has a fetch with that url

the user then need to implement the endpoint

(so the docker container for example needs that code that handles the request)

[granite topaz]

yea so are you asking suggestion for a testing url or what lol

[sand rock]

now that is funny bc i forgot about the proxy options so i was thinking of an endpoint to use for that fetch call

at this point, we could change the question to

• What should be the name of the option to change the endpoint that updateTokenQueues uses to talk to the rest proxy
• Should it have a default value
  • What should it be that default value if we add that