in this page https://myanimelist.net/animelist/user after pressing edit on some anime then history in "Episodes watched" row, it returns anime episode details.
Ex:
Dandadan Episode Details
Ep 2, watched on 10/16/2024 at 14:34 Remove
Ep 4, watched on 10/16/2024 at 14:34 Remove
Ep 3, watched on 10/16/2024 at 14:34 Remove
Ep 2, watched on 10/16/2024 at 14:33 Remove
@itszux: Hi! There is no API endpoint you can use to retrieve your watch history for a series.
But you can still call ajaxtb.php passing your OAuth access token as a form of authentication.
The output is in HTML, so you would have to manually parse it to extract the full history. For example:
> GET https://myanimelist.net/ajaxtb.php?detailedaid=12815
> Authorization: Bearer MY_ACCESS_TOKEN
Where 12815 is the anime ID.
You will get something similar to this. It should be quite easy to parse:
@itszux: Hi! There is no API endpoint you can use to retrieve your watch history for a series.
But you can still call ajaxtb.php passing your OAuth access token as a form of authentication.
The output is in HTML, so you would have to manually parse it to extract the full history. For example:
> GET https://myanimelist.net/ajaxtb.php?detailedaid=12815
> Authorization: Bearer MY_ACCESS_TOKEN
Where 12815 is the anime ID.
You will get something similar to this. It should be quite easy to parse:
(It keeps going...)
@ZeroCrystal yeah it worked like that, but will this be counting on the API usage or it will be considered normal scraping?
As with scraping comes the risk of getting banned or interfered by recaptcha or cloudflare
The main issue with these endpoints is that they are not "real" endpoints. They were added as a temporary solution to make certain parts of the website available until they could re-implement them as proper API endpoints, but they never did.
POST requests stopped working due to their incompatibility with reCAPTCHA, but the GET requests should still be working.
The main issue with these endpoints is that they are not "real" endpoints. They were added as a temporary solution to make certain parts of the website available until they could re-implement them as proper API endpoints, but they never did.
POST requests stopped working due to their incompatibility with reCAPTCHA, but the GET requests should still be working.
I have another question, I don't if I should open a new topic for it or not.
I want to implement mal oauth in my chrome extension so I put the app type as "other", and it gave me a clientId.
is it safe to use the clientId on client side without hiding it in a server. as of my understanding even if I put it in the back-end I still need to send it to the client-side code.
in your documentation you said its better to hide it in a server but I want to see another extension that uses mal oauth "mal sync", and its clientId was visible
ZeroCrystal said: It is important to distinguish between two types of clients: confidential clients can maintain the confidentiality of their credentials (e.g., Client Secret), while public clients are incapable of secure client authentication. You can read more about this here:
2.1. Client Types
OAuth defines two client types, based on their ability to
authenticate securely with the authorization server (i.e., ability to
maintain the confidentiality of their client credentials):
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
[...]
user-agent-based application
A user-agent-based application is a public client in which the
client code is downloaded from a web server and executes within a
user-agent (e.g., web browser) on the device used by the resource
owner. Protocol data and credentials are easily accessible (and
often visible) to the resource owner. Since such applications
reside within the user-agent, they can make seamless use of the
user-agent capabilities when requesting authorization.
When you create a new API application on MAL, you're asked for an App Type. Web corresponds to a confidential client, while Android, iOS, and Other are all aliases for a public client.
Confidential clients will receive a Client ID and a Client Secret. Public clients will only receive a Client ID.
If you're developing a browser extension, it must be considered a public client and you should choose Other as the App Type.
The Client ID is not confidential and should not be treated as a secret. It can easily be extracted from any application, including MAL's official mobile app. It can be distributed together with your application. The owner of a public client is not responsible for the (mis)use of the Client ID, it's the authorization server (MAL) that must enforce proper security policies.
ZeroCrystal said: It is important to distinguish between two types of clients: confidential clients can maintain the confidentiality of their credentials (e.g., Client Secret), while public clients are incapable of secure client authentication. You can read more about this here:
2.1. Client Types
OAuth defines two client types, based on their ability to
authenticate securely with the authorization server (i.e., ability to
maintain the confidentiality of their client credentials):
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
[...]
user-agent-based application
A user-agent-based application is a public client in which the
client code is downloaded from a web server and executes within a
user-agent (e.g., web browser) on the device used by the resource
owner. Protocol data and credentials are easily accessible (and
often visible) to the resource owner. Since such applications
reside within the user-agent, they can make seamless use of the
user-agent capabilities when requesting authorization.
When you create a new API application on MAL, you're asked for an App Type. Web corresponds to a confidential client, while Android, iOS, and Other are all aliases for a public client.
Confidential clients will receive a Client ID and a Client Secret. Public clients will only receive a Client ID.
If you're developing a browser extension, it must be considered a public client and you should choose Other as the App Type.
The Client ID is not confidential and should not be treated as a secret. It can easily be extracted from any application, including MAL's official mobile app. It can be distributed together with your application. The owner of a public client is not responsible for the (mis)use of the Client ID, it's the authorization server (MAL) that must enforce proper security policies.
@ZeroCrystal what about access tokens, if it gets misused by the user, the whole application (clientID) will get a temporary ban or just the user (owner of that access token)?
@ZeroCrystal what about access tokens, if it gets misused by the user, the whole application (clientID) will get a temporary ban or just the user (owner of that access token)?
@itszux Just the user. Or rather, I think the IP address gets temporary banned rather than the user himself.