add trackers support

[tachimanga]

Note: the Anilist & MyAnimeList clientId should be replaced with official clientId, and set callback url to suwayomi://oauth/anilist and suwayomi://oauth/myanimelist

MyAnimeListApi.kt
AnilistApi.kt

close #80

[Syer10]

Do you think you would be able to add GraphQL endpoints for these?

[tachimanga]

Hi @Syer10, I'm sorry that I have very limited knowledge about GraphQL.

[Syer10]

I'll try to take a look at implementing it when I have time, I'll push to this branch so that it can be included in the PR.
We have deprecated the REST api and all future development is to take place in the GraphQL api(under the suwayomi.tachidesk.graphql package). So we need GraphQL endpoints for these before merging.

[tachimanga]

BTW, the related PR to Sorayomi can be found here: Suwayomi/Tachidesk-Sorayomi#236

[Syer10]

@tachimanga I did a bunch of cleanup as well as add GraphQL support. Can you verify that everything still works as intended?

One thing to note is that I changed the track/bind endpoint to add a mangaId query parameter since I removed it and other unused parameters from the TrackSearch model. So this will have to be accounted for in Sorayomi as well as other minor model changes I did.

[tachimanga]

@Syer10 I am a Kotlin beginner, and my code often shows some Java flavor. I have learned a lot from your modifications, and I will make the necessary changes to Sorayomi to handle the endpoint changes. I will reply once I have finished the modifications.

[tachimanga]

@Syer10 Everything is working great! It was a good idea to remove mangaId from the MangaTrackerDataClass.
I have made the corresponding changes to the Sorayomi code. You can check the modifications in this commit: Suwayomi/Tachidesk-Sorayomi@2b227ab

[Syer10]

Great! I'll look into the client ids in the next few days, we should be able to merge it sometime soon.

[tachimanga]

@Syer10 Some notes about the callback URL.
In the configuration for MyAnimeList and AniList, the callback URL must be a fixed value. Currently, the scheme for the callback URL is set as suwayomi://, which makes it easy for us to complete the OAuth process on the client-side.
The flow is as follows: MyAnimeList/Anilist -> Oauth Handler(client-side).
However, if we need to implement the "add trackers" feature on the web UI, the scheme must be http(s):// to complete the process. Of course, we can use different client IDs for different front-ends. The client-side can still use suwayomi://, but the callback URL for the web UI cannot be set as a fixed value, such as http://127.0.0.1:4567/oauth/myanimelist, because the IP might not always be 127.0.0.1. Therefore, we need an intermediate page where users can enter the local IP to complete the OAuth process.
The flow would be as follows: MyAnimeList/Anilist -> Proxy Page (on the internet) -> Callback Page (on the local network).

[Syer10]

Hmm, I see.
@schroda do you think this would be possible?

[AriaMoradi]

The flow would be as follows: MyAnimeList/Anilist -> Proxy Page (on the internet) -> Callback Page (on the local network).

It might be possible to set it up via github pages? Does their oauth request accept additional arguments so we could pass it the real redirect url?

Alternatively this could be the first electron only feature in WebUI.

[tachimanga]

@AriaMoradi Github Pages is OK, and when the OAuth process is completed, it will jump back to a URL such as suwayomi://oauth/myanimelist?code=def50200c056... with no additional arguments.

If we implement the tracker setting in the web UI, we can set up a github page with the URL as https://suwayomi.org/oauthproxy-anilist.html. Then, when they jump back, they will be redirected to https://suwayomi.org/oauthproxy-anilist.html?code=def50200c056.... on the proxy page, then we can redirect to http://{local_ip_user_input}:4567/webui/oauth/anilist?code=def50200c056 to complete OAuth process.

[Syer10]

I've decided to just merge it, and disable the endpoints until we have a working auth solution

[renjfk]

There's also Auth Pin option from AniList at least:

If you are absolutely unable to have a Http or application URI scheme redirection you can use the Auth Pin redirect URL. After the user has authorized your application they will be redirected to a page requesting them to manually copy & paste the code/token into your application.
To enable this, on your AniList v2 client page, set your Client Redirect Uri to https://anilist.co/api/v2/oauth/pin.

[renjfk]

Now that I think about it, alternatively the Suwayomi-Server could be transparent regarding OAuth client and the actual client e.g. WebUI should determine OAuth client therefore you could have multiple URI scheme redirections.

So basically the original initiator gets the token if it's supported by the UI type, stores it to server and the server makes use of it amongsts different UIs.

You can think of it like, Suwayomi-Server will act like transparent proxy while fetching the token and then grab it.

[taos15]

That is how it works, kind o. after a tracker is authenticated, the token get served in the server, and any client (even if they dont have a login implementations) can use it and make authenticated called to the tracker. A Pr I was working on give you another OATH2 implementation (authentication code), which let you set the redirect uri instead of using the hardcoded one, then the client can pick/implement what redirect uri will be use for authenticating. Since tracking has just been implemented in the webUI, I have put move the PR to low priority, but I am thinking on finish it in the future. The logic for the implementation can be reused to add oath2 authentication to secure suwayomi.