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

But an a rough `fetch` equivalent complains about CORS:


Rant: the MU commenting system garbles the code.

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 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 userscript 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.

Last edited by Klaster_1 at 7:00 am, May 15 2022

What do you mean by this?


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


So, my hesitation to do so is more related to my admittedly 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.

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

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 user 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 assigning old version IDs (200591 max), and now use only new version IDs for newly added series. Am I right?

That is correct.

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

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

Last edited by Manick at 1:57 pm, May 15 2022

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 admins!)



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.mang aupdates

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 admin 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.

Last edited by Manick at 3:36 pm, May 15 2022

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)

Last edited by endantarathr at 8:42 pm, May 28 2022

(deleted)

Last edited by endantarathr at 8:42 pm, May 28 2022

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.

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.

Last edited by chocolatkey at 6:31 pm, May 15 2022

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.