Added a new endpoint, youtube/createaccesstoken/{refreshToken}

[WeeeeeeeeeeS]

Added a new endpoint, youtube/createaccesstoken, to allow users to create access tokens.

Why this change?
@kikkia added OAuth tokens in userdata: edd6646

It would be beneficial for users to create refresh tokens and use them on the client side.
Why not implement it client-side? Because of IPv6 rotation

[WeeeeeeeeeeS]

Should I write the README now? I made the requested changes

[devoxin]

Yes please

[kikkia]

It's likely not a big deal, but just a heads up, it is not a good practice to log any sort of tokens or credentials. Also as for the ipv6 rotation I have found that at least as of now it doesnt really matter. It seems like there is no (at least that I have hit) ratelimits based on ip for these. It seems all account based.

[devoxin]

Access tokens have a finite lifespan anyway and logging is the only practical way to display the tokens to the user.

[kikkia]

I am referring to using the refreshtoken which iirc will be logged on each request to this endpoint since its in the path

[WeeeeeeeeeeS]

it is logged as "debug"

[WeeeeeeeeeeS]

I am referring to using the refreshtoken which iirc will be logged on each request to this endpoint since its in the path

can we even block that

[devoxin]

Refresh token is also logged once during the oauth account linking process. I don't think it's a big deal — ideally users have their nodes secured anyway and omit sensitive information when submitting logs (which would include things like voice connection data so token, endpoint, session ID and user ID)

[kikkia]

It's likely not a big deal - Yeah I doubt its a huge deal, we are talking about something that's not exactly a business or that is held to the same security standards. My professional background is in infosec adjacent stuff so it just stands out to me in particular, but I see a couple things that it could pop up with.

1. Some user posting logs in the help channel leaking their refresh tokens unknowingly
2. In the case of users with log aggregators they may be sending these tokens in plaintext to other services, increasing the surface of the attack and potentially leaking them outside of the intended scope (for example if more people have access to logs/bug reports with attached logs, pasting to pastebin, etc)
3. It gives the people who run LL and are pretty unknowledgeable another gun to shoot themselves in the foot.

Again, I think it's unlikely a real issue for anyone knowledgeable but I just wanted to bring attention to the fact that it is happening for people who care and that it is not a good security practice.

[WeeeeeeeeeeS]

I mean, posting the logs exposes more security issues, not just 'burner accounts,' voice sessions, public guild IDs, what users play, user data (the one you also use), server IPs, user IPs, and more.

You can just ignore this endpoint and use client-side code instead

[topi314]

if you don't want the token to be logged it should be sent as a POST body, which imo would be a good idea.

voice sessions & guild ids are irrelevant data anyway, you cant do anything with those

[kikkia]

I am using my own client side implementations, I just wanted to raise this as a bad practice. If this was in a professional setting the likely best case would be to do the POST like topi said and then also add something around here to disallow payload logging to this endpoint (or others if wanted)

[devoxin]

I don't think there's any way around it short of disabling logging or implementing a logging filter to mask tokens. Even on POST and PATCH I'm pretty sure the body gets logged.

Voice data does matter because provided that data is valid, users can connect to the voice socket as you and send data. Also IDs are considered PII by Discord so when users upload their logs to Discord they are actually dubiously sharing IDs

[WeeeeeeeeeeS]

if you don't want the token to be logged it should be sent as a POST body, which imo would be a good idea.

voice sessions & guild ids are irrelevant data anyway, you cant do anything with those

2025-04-08T14:34:05.497+03:00 INFO 26428 --- [Lavalink] [ XNIO-1 task-2] l.server.io.RequestLoggingFilter : POST /youtube/oauth, client=0:0:0:0:0:0:0:1, payload={
"1//0315...."
}

it does log lol

i had
includePayload: true
nvm

[topi314]

Voice data does matter because provided that data is valid, users can connect to the voice socket as you and send data

unless you run a 24/7 connected music bot this is not relevant, just disconnect your bot and they are invalid

[devoxin]

/shrug

I don't think this will get changed unless I can figure out a way to avoid logging the refresh token when completing the oauth flow. I think there's worse information logged by the server and people don't always mask their access tokens either. Always open to suggestions on how to mitigate the above