Report Robstersgaming's Profile

Statistics

Anime Stats
Days: 49.5
Mean Score: 8.26
  • Total Entries604
  • Rewatched1
  • Episodes3,016
Last Anime Updates

Access to this list has been restricted by the owner.

All Manga Stats Manga Stats
Days: 0.3
Mean Score: 10.00
  • Total Entries1
  • Reread0
  • Chapters60
  • Volumes0
Manga History Last Manga Updates
Death Note
Death Note
Jun 19, 2024 3:16 PM
Reading 60/108 · Scored 10

All Favorites Favorites

Anime (10)
Character (10)
People (6)

All Comments (10) Comments

Would you like to post a comment? Please login or sign up first!
ZeroCrystal Aug 1, 2021 9:28 AM
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. ¯\_(ツ)_/¯
ZeroCrystal Aug 1, 2021 4:07 AM
I'll take care of that. Thanks for your report!
ZeroCrystal Jul 31, 2021 9:47 AM
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).
ZeroCrystal Feb 7, 2021 12:26 AM
From: Authorisation flow for the new MAL API using OAuth 2.0
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.

  1. 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.
  2. 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.
ZeroCrystal Jan 8, 2021 10:14 AM
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.
ZeroCrystal Jan 8, 2021 10:01 AM
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.
ZeroCrystal Jan 8, 2021 2:33 AM
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.
ZeroCrystal Jan 4, 2021 7:45 AM
Thanks! Good luck with your project. ^^
ZeroCrystal Jan 4, 2021 6:40 AM
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.

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.
ZeroCrystal Jan 4, 2021 3:03 AM
From: Authorisation flow for the new MAL API using OAuth 2.0
Yes, it's standard procedure. The Client Secret is the only element that mustn't be disclosed.
All Comments

MoreTop Anime

  1. 1 Sousou no Frieren
  2. 2 Fullmetal Alchemist: Brotherhood
  3. 3 Steins;Gate
  4. 4 Shingeki no Kyojin Season 3 Part 2
  5. 5 One Piece Fan Letter

MoreTop Airing Anime

  1. 1 Kusuriya no Hitorigoto 2nd Season
  2. 2 One Piece
  3. 3 Tian Guan Cifu Short Film
  4. 4 Tu Bian Yingxiong X
  5. 5 Doupo Cangqiong: Nian Fan

MoreMost Popular Characters

  1. 1 Lamperouge, Lelouch
  2. 2 Monkey D., Luffy
  3. 3 Levi
  4. 4 Lawliet, L
  5. 5 Roronoa, Zoro
It’s time to ditch the text file.
Keep track of your anime easily by creating your own list.
Sign Up Login