Under the section there is a create session token operation. You can use that to using name and . It will return the JWT. 2g654v

Yeah, that's what I tried first. This curl request works:

curl "https://api.mangaupdates.sitesdebloques.biz/v1//" -X PUT -H "Content-Type: application/json" -d "{"name":"klaster_1","":"foobar"}"

But an a rough fetch equivalent complains about CORS:

fetch('https://api.mangaupdates.sitesdebloques.biz/v1//',{method: 'PUT',headers: {'Content-Type': 'application/json'},mode: 'cors',body: JSON.stringify({name: 'klaster_1', : 'foobar'})})

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.mangaupdates.sitesdebloques.biz/v1//. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

Rant: the MU commenting system garbles the code.

You also only have one session, so if you on the API or browser it will log you out on the other.

Does "one session" limitation means only a single JWT at a time? If true, what if I want to access API from different applications? Or I should just reuse the same token across the apps? Does the token expire at the same time as the session, what's the TTL?

What would you need to get your script working? Originally we designed this to be used programmatically by a backend service, not by a browser, so I need to know more about your use case.

You can allow CORS from anywhere by setting the "Access-Control-Allow-Origin" header to "*" (MDN). Just make sure it works with fetch. My use cases:

1. A script that checks all items in a list and marks completed or scanlated items as checked. Helps managing wishlists, I have separate lists for ongoing and completed, but not fully scanlated series. At the moment, I just fetch and parse item pages directly, one request per item. With JSON, no parsing would be necessary and less data to transfer.
2. A custom browser extension to indicate amount of series with unread chapters available.

Rant: the MU commenting system garbles the code.

What do you mean by this?

Does "one session" limitation means only a single JWT at a time? If true, what if I want to access API from different applications? Or I should just reuse the same token across the apps? Does the token expire at the same time as the session, what's the TTL?

You only have one JWT active in the system at a time. If you from 5 places, the same JWT will be returned. If you from any one of those places, it will clear that single session, essentially logging you out from all 5 places at the same time.

You can allow CORS from anywhere by setting the "Access-Control-Allow-Origin" header to "*"

So, my hesitation to do so is more related to my ittedly low knowledge of CORS exploits and security concerns. Setting it to "*" seems like a bad idea.

We're sending credentials via a bearer token, so technically we shouldn't be vulnerable to most of the attacks that are possible. However, in order to make this work, I did some research this morning and I think I'd have to have the following:

• Access-Control-Allow-Origin: *
• Access-Control-Allow-Headers: Authorization

I'm not 100% ready to commit to that until I have more time to research potential security implications, so I'd like a bit more time to study it.

Quote from endantarathr

Can you please allow specifying a series (series ID) for /releases/rss?

It would be useful to add a link in the series page which uses the API to generate a RSS feed for releases of the series, so that s can receive new release notifications in RSS reader.

I think I can do this without too much effort. I'll reply here when done.

I'm not 100% ready to commit to that until I have more time to research potential security implications, so I'd like a bit more time to study it.

Sure, take your time.

In short, the purpose of CORS is to limit resource access to legitimate origins, which helps to protect from attacks like CSRF. Since we are talking about a standalone API designed for consumption outside of browsers, it makes no sense because a) non-browser agents do not have an origin (there's no website location to check against, see cURL) and b) you don't know beforehand where the API will be accessed from. An example of a valid CORS application would be a single page application and the corresponding HTTP API endpoints, preventing other websites sending API requests. Besides, CORS can be easily circumvented by a proxy that adjusts the headers to look OK from the browser point of view (like this one). I advise reading this HN thread for additional insight.

Looks like you stopped asg old version IDs (200591 max), and now use only new version IDs for newly added series. Am I right?

Quote from YuriM

Looks like you stopped asg old version IDs (200591 max), and now use only new version IDs for newly added series. Am I right?

That is correct.

Quote from endantarathr

Can you please allow specifying a series (series ID) for /releases/rss?

This is added. Here is an example: https://api.mangaupdates.sitesdebloques.biz/v1/series/17360452316/rss

Edit: I also added a little feed link next to the series title on each page.

Quote from Diavol90

With the release of the api, will it be possible to have an Android app? Why is an official app site missing on mobile?

I made an Android app based off the site. Granted I haven't updated in a bit as I have been busy. (and currently refactoring the codebase)

Although now that an actual API has been released, I will start using that. (thanks s!)

Quote from Manick

It's "missing" because I'm the only developer, and I just don't have as much time as I used to. We're most likely going to ask the community for developer help next week. We think the most glaring thing that needs to happen is a new UX and UI if MU is going to stay relevant, ...

Quick question though, I was skimming through the API and some of the features that are on the site I did not seem to find on the API. (notably the list of series stats by time period) Did I happen to miss it?

https://play.google.com/store/apps/details?id=hikaru.mangaupdates

That is available on the series search function. Look at the order by options.

Edit: you can also use include rank metadata option to include the current positions. The series search function powers the What's New, Series Stats, List Stats and Series Info pages.

The website is broken up into two pieces on the back end. The API piece is completely API driven and is the same one that you have access to (I have hidden some of the functions from the public schema file, but you still have access to them technically). The front end is a PHP app that uses Open API Generator to access the API.

Not sure where put this but I guess here since it's about the update.

I don't think the new links are a good idea because if someone copy the link with the title it has at the end, it could be wrong if they copy it before the correct title is put. Especially on other sites. It's best to avoid putting the names especially if an author comes across it and sees the name that's not official or just some random romanization that could also be incorrect.

(deleted)

(deleted)

Quote from endantarathr

Apparently the title in the new URL is optional, and it works even if it is missing, truncated, or replaced by something else.

i.e. All these will work:
https://mangaupdates.sitesdebloques.biz/series/7z3yqqk/loremips ...

Glad the link work no matter what but I think the titles at the end still aren't a good choice. Esp when it comes to manhwa since authors are still up in grip when it comes to titles.

The front end is a PHP app that uses Open API Generator to access the API.

Is this change why the performance of the website has decreased? Requests to e.g. series pages used to take <100ms from my location, and now they take 250ms-1.5s.

API requests are still extremely fast, same speed as the site used to be.

I would strongly suggest adding cache control headers to your API endpoints. They would help reduce traffic from compliant web clients, and can (optionally) be used in combination with a proxy (nginx, cloudflare etc) to hint how long content should be cached and how revalidation should occur.

Generally yes, but I typically get on par performance with how the site used to work. It's going slow right now because we've got several people attempting to scrape the site (not via API, which I'm not as against), in addition to google bot doing its thing. I've been banning IPs and changing robots rules for the past hour.