get_tags_from_EH API $uri

[uap4]

I tried LANraragi. It looks like my ISP is blocking E-Hentai with subdomains (PR_CONNECT_RESET_ERROR browser error) but not ExHentai. Then even with $enablepanda, because

LANraragi/lib/LANraragi/Plugin/Metadata/EHentai.pm

Line 234 in f22de13

my $uri = 'https://e-hentai.org/api.php';

, request failed. I changed to "ex", but then there were redirects to the forum. Then I changed $ua in

LANraragi/lib/LANraragi/Plugin/Metadata/EHentai.pm

Line 236 in f22de13

my $ua = Mojo::UserAgent->new;

so that it was like in

LANraragi/lib/LANraragi/Plugin/Metadata/EHentai.pm

Line 83 in f22de13

$lrr_info->{user_agent},

. I don't really understand how, but it works.

It is likely that there will be another problem that when requesting https://e-hentai.org/api.php, redirection to CloudFlare (I've only tested this in the Firefox browser.). But the EHwiki contains an address on the third-level domain https://api.e-hentai.org/api.php, and when accessing it through a browser, no redirection occurs. Therefore, it is better to use https://api.e-hentai.org/api.php address?

For myself, I will probably copy the plugin and write it in my own way.

[Difegue]

As you've seen, the EH API is not available under the ex context.
The cloudflare block happened a few weeks ago already, but had been removed later on: I suspect EH is now applying CF firewalls whenever it encounters too much traffic at a given time.

I'd seen that the CF block was affecting the API URL we used, but to my knowledge the api.e-hentai.org/api.php TLD did not exist at the time! If it's been explicitly added as an alwayys-unblocked endpoint now, the LRR plugin should use it as a default.

[uap4]

Well I do not know.

As you've seen, the EH API is not available under the ex context.

It works in LANraragi with my modifications. And from Firefox I can open https://exhentai.org/api.php, receive {"error": "Empty JSON Request"}, in F12 press edit and send again, select POST, insert json, received correct {"gmetadata".

TLD did not exist at the time! If it's been explicitly added as an alwayys-unblocked endpoint now, the LRR plugin should use it as a default.

https://ehwiki.org/action/history/API
Revision as of 16:42, 15 January 2016 - API URL: http://g.e-hentai.org/api.php
Revision as of 13:27, 25 January 2017 - API URL: https://e-hentai.org/api.php
Revision as of 21:20, 25 February 2017 - API URL: https://api.e-hentai.org/api.php

While it somehow works with my changes - it's okay for me. I hope that it will not break.

[Difegue]

Hmm, you're right that the url hasn't changed in the wiki in a while -- I think I tested both forms during the first CF block and both were blocked, but maybe that's been fixed now. 👍

Similarly, I never got the api to work on ex before, but I guess it does work now if you give it the proper cookies! Feel free to push your changes to the plugin as a PR if you have the time, I'll gladly integrate them. 😁

(If not I'll try to get this stuff improved later today)

[uap4]

Feel free to push your changes to the plugin as a PR

Sketched out adding a custom API URI field. I don't know much about perl and github, so it's not good for PR. But for example, you can see the comparison, probably. dev...uap4:patch-1

Also in the description g. not relevant for a long time.

LANraragi/lib/LANraragi/Plugin/Metadata/EHentai.pm

Line 29 in c287836

description => "Searches g.e-hentai for tags matching your archive.",

[Difegue]

That'd work and actually looks pretty good code-wise, although I'm not sure the API field changes often enough to warrant making it a setting. 😛

It's true that g. hasn't been a thing forever, I'll think about editing the description later.

[Difegue]

Improved in 1173826.