I took a closer look before reporting your issue. You can solve it simply by adding "nsfw=1" to your query string.
It's an undocumented feature that prevents several shows from appearing on your list. Usually, they're not even NSFW, but that's how it works. ¯\_(ツ)_/¯
You can send a message to Xinil, or you can describe it to me and I can file the issue for you (but in both cases expect a long time before a solution is deployed).
Retrieve the user's watching list and cache it locally. You can do it by using the "Get user anime list" endpoint, passing "status=watching" and "fields=num_episodes,my_list_status" as part of the query string. The returned anime list contains both the number of total episodes and how many of them were already watched by the user.
When the user wants to update a series, your application should first check in the cached version of the anime list how many episodes were already watched, increment it, and send the appropriate PATCH request.
In this way, you can send a single request for each update, assuming that all entries are listed in the watching list.
If you're working on a regular website, then you can create a unique Code Verifier per each request and store it temporarily inside a cookie. You can assume that a user will perform the authorisation procedure in a few minutes since the code was generated, so you can set the cookie's expiration date to 30 minutes after its creation (or something similar). I'm following a very similar approach on my website.
You should generate new Code Verifiers on a per-request basis. In other words, all your users should use a unique code every time they have to re-login via MAL. Theoretically, you should never issue two or more tokens using the same Code Verifier during the entire lifetime of your application, but don't waste too much time looking for the perfect strategy.
Unfortunately, there's no concrete information available. I only know that each API client has a “very generous” amount of requests, but nothing more. Personally, I never reached the limit, so I have no idea to which value it is set.
Either way, the rate limit should only apply to API calls. You can keep issuing or refreshing Access Tokens without thinking too much about it.
As you've guessed, the PKCE (Proof Key for Code Exchange by OAuth Public Clients) protocol was developed to prevent eavesdroppers from intercepting and abusing OAuth-related web requests.
The problem is that MAL implemented an obsolete and insecure version of the PKCE protocol. The reason why the Code verifier and the Code Challenge have different names is that they are indeed diverse entities (or should be, at least).
The "code_challenge_method" parameter listed in Step 2 of the guide is used to choose which version of the PKCE should be used. MAL only supports the "plain" method, meaning that the Code Verifier and the Code Challenge are equal. However, modern implementations of the OAuth protocol use the "S256" method, where the Code Challenge is given by hashing the Code Verifier using the SHA2-256 function. In this second case, having access to the Code Challenge is not enough to discover (and abuse) the Code Verifier.
The "S256" method protects against eavesdroppers observing or
intercepting the "code_challenge", because the challenge cannot be
used without the verifier. With the "plain" method, there is a
chance that "code_challenge" will be observed by the attacker on the
device or in the http request. Since the code challenge is the same
as the code verifier in this case, the "plain" method does not
protect against the eavesdropping of the initial request.
The use of "S256" protects against disclosure of the "code_verifier"
value to an attacker. Because of this, "plain" SHOULD NOT be used and exists only for
compatibility with deployed implementations where the request path is
already protected. The "plain" method SHOULD NOT be used in new
implementations, unless they cannot support "S256" for some technical
reason.
The "S256" code challenge method or other cryptographically secure
code challenge method extension SHOULD be used. The "plain" code
challenge method relies on the operating system and transport
security not to disclose the request to an attacker.
If the code challenge method is "plain" and the code challenge is to
be returned inside authorization "code" to achieve a stateless
server, it MUST be encrypted in such a manner that only the server
can decrypt and extract it.
I'm not sure why MAL decided to use the "plain" method, but there's not much we can do about it. Either way, you should generate random Code verifiers / Code Challenges for your application.
All Comments (10) Comments
It's an undocumented feature that prevents several shows from appearing on your list. Usually, they're not even NSFW, but that's how it works. ¯\_(ツ)_/¯
There's not a function to increment by 1 the number of watched episodes of a series, but you can still optimise the amount of requests you make.
In this way, you can send a single request for each update, assuming that all entries are listed in the watching list.
Either way, the rate limit should only apply to API calls. You can keep issuing or refreshing Access Tokens without thinking too much about it.
The problem is that MAL implemented an obsolete and insecure version of the PKCE protocol. The reason why the Code verifier and the Code Challenge have different names is that they are indeed diverse entities (or should be, at least).
The "code_challenge_method" parameter listed in Step 2 of the guide is used to choose which version of the PKCE should be used. MAL only supports the "plain" method, meaning that the Code Verifier and the Code Challenge are equal. However, modern implementations of the OAuth protocol use the "S256" method, where the Code Challenge is given by hashing the Code Verifier using the SHA2-256 function. In this second case, having access to the Code Challenge is not enough to discover (and abuse) the Code Verifier.
Quoting from the IETF RFC 7636:
I'm not sure why MAL decided to use the "plain" method, but there's not much we can do about it. Either way, you should generate random Code verifiers / Code Challenges for your application.
Yes, it's standard procedure. The Client Secret is the only element that mustn't be disclosed.