iv-org
[Feature request] API Keys
Is your feature request related to a problem? Please describe. With the recent adoption of Anubis on my instance, Fjixu's, and on 420129, legitimate uses for the API (such as third-party clients) are now blocked. While video playback likely won't work anyways for the time being, it'd be nice to start offering support for it again, at least for other routes.
Describe the solution you'd like
Implement a way for Invidious to issue API keys (possibly using something similar to the authenticated routes) and add a config option to block any requests not using one. The host can then allow requests to /api/* and either use rate limiting or completely block any key making excessive requests.
Describe alternatives you've considered It is also possible to allow multiple User-Agents via Anubis. AFAIK there's currently no app that would use a custom User-Agent header (FreeTube is currently considering one,) but it would be better than completely blocking API usage. The downside of this is that this alone would not be enough to deter bots - it is incredibly easy to use a fake User-Agent and bots regularly pose as browsers.
Additional context N/A
How would you send the API key though? Using a bearer token?
I'm also wondering whenever if it is really worth implementing that into the invidious code. Compared to just have that in your reverse proxy, at least for flexibility.
API keys would make sense for private usage but not for public instances. Since if the key is public, like hardcoded into the freetube code, this is the same as whitelisting as user agent. In such case, you can do that using your reverse proxy.
I was thinking it would be implemented in a similar matter to how authenticated routes are - you go to a page on Invidious where it asks if you want to make a key and it responds with one. The difference being that this is not strictly for accounts, although it is per user.
Either that or you can add a page/section in the settings for making API keys, similar to how GH and other apps are designed.
My understanding was that the user would go to the authentication page, generate a bearer token and then enter that into the FreeTube settings. That way if creating accounts on your instance is an "ask the person hosting the instance to create one for you" thing, it would allow users with accounts on the instance to use said instance in a 3rd party client like FreeTube. That way it would also not require anything additional for clients that already use the authenticated API endpoints e.g. Yattee.
As for handling it that means you just need to check if the token in the header matches one in the database.
Agree that freetube should NOT have to use personnal account or any api key that can permit to identify users … Please keep stuff easy to use for users even more for people using instance list to automaticly change public invidious instances. For me the best choise is to make a issue to anubis in order to implement a user agent white list.
For me the best choise is to make a issue to anubis in order to implement a user agent white list.
This already exists. The problem is, like mentioned in the OP, having a custom UA whitelisted makes it incredibly easy to abuse.
Why people not try to use a fail2ban rules to keep people (company) who scrap too much ?
Some use specific user agent and some just flood. Both are easy to spot and ban. Others probably not stress test the server and should not be an issue.
Is there is some bad actor I miss ?
fail2ban is a completely separate program that most server admins already use. It's meant for validating logins, not for preventing LLM scraping websites.
You can't just block a certain useragent and hope it works. Most nowadays use browser UAs, which is the entire point of Anubis and similar projects. If it was that simple, trust me, Anubis, CloudFlare, captchas, etc would not exist.
Anyways, please do not use this issue to discuss sysadmin problems. This is for a feature request for API keys, not for the validity of AI blockers.