Hi @stephaje, thanks for making the issue!

This should be possible currently by doing a GET request to the following endpoint:

127.0.0.1:3080/api/watched

Though you will have to provide the Authorization header set as the users auth token.

That request should return all the information you'd need though, it returns the users whole watched list, which includes the status, rating, thoughts, content info, activity, etc.

Do you think a page where users can generate API Keys for this would be better? Then keys could have limited scope and be revoked at a later date.

I agree API keys would be better here, as well as the ability for an admin to pull all data.

I'd like to work on this issue. Can you please assign ?

Hi @titanventura, thanks for commenting, you sure can, I will assign you.

Just to clarify, since the issue title is different, this task would be to create a way for users to make API Keys for their account.

The user should be able to create, remove and view their active api keys in their profile page.

The API keys should also have a limited scope, to start we can make them only have access to the watched routes for the user.

It's a complex task, so it may be beneficial if we came up with a plan for tackling it.

My basic thoughts are a new table and module for managing user api keys and to extend the auth middleware to differentiate auth tokens vs api keys (and somehow restrict their scope here). To differentiate, we could simply make api keys use a different http header for auth and ensure they wont successfully pass as a user token.

Let me know of any questions/thoughts you have

Hey @IRHM , the approach you suggested seems valid IMO. Here are some questions

1. should we treat API keys similar to passwords wherein, the user can create, use and remove the API keys but not view them. this will mean that we will hash the API keys just like we do with passwords.
2. if we can allow the user to view the API key, should we store it in an encrypted format in the database ?
3. Should we allow creating multiple API keys ?

I guess we are clear that we need a new middleware to authenticate the routes using API keys.

Please feel free to add your opinions.

refer: https://www.freecodecamp.org/news/best-practices-for-building-api-keys-97c26eabfea9/

Hey @titanventura, thanks for looking into it!

I don't see any reason to hash the api keys, I think we can just simply store them plaintext in the database.

If we can allow the user to make as many keys as they want, that would probably be the best.

I'm thinking the new table could store, the user id (foreign key), the api key (we generate) and a name/note that the user can give it (to remember what they used it for).

For the middleware, I'm guessing we could add a check to the top of the existing one (if is api key, by checking if api key header is present?), if it looks like an api key, we can move on to the api key middleware.

The simplest way for now, If possible, the api key middleware could also look at the route requested and only continue if it's a GET /watched (or any other routes you think should be allowed too).

Feel free to add your opinions too!

Sure, let me factor in all these inputs and submit a draft PR.
Thanks !

Hey @IRHM , I've created a draft PR for the same. Please have a look
#379