feature request: Improve fantia upload support

[hdk5]

There are at least three types of media that can be attached to fantia post.
Related: danbooru/danbooru#5580

For all three cases below, ideal behavior would be - both direct image url, and page address ref (or url that can be converted into one by danbooru), are present

1. post_content_photo - somewhat working

For example, https://fantia.jp/posts/2302310
Each image has to be open individually.

On https://fantia.jp/posts/*/post_content_photo/* page:

• icon appears in address bar;
• by clicking on the icon, only this page url without direct image url is sent to /uploads/new - danbooru can't extract the image;
• by using the context menu item, direct image url, as well as this page as ref, are sent to /uploads/new - danbooru can extract both the image and page address (assuming PR above is merged)

If I "Open Image in New Tab", on https://cc.fantia.jp/uploads/post_content_photo/file/* page:

• icon does not appear in address bar;
• by using the context menu item, direct image url is sent both as url and ref - danbooru can extract the image, but not the page address

2. album_image - not working

For example, https://fantia.jp/posts/2293136
Each image has to be open individually.

Clicking on the image opens https://fantia.jp/posts/*/album_image?query=* page, which redirects to https://cc.fantia.jp/uploads/album_image/file/*/* page. Here:

• icon does not appear in address bar;
• by using the context menu item, the original redirect page url is sent to /uploads/new as url - danbooru can't extract the image;
• direct image url can still be copied to upload form manually;

3. download / post_content/file - not working

For example, https://fantia.jp/posts/61560
Similar to album_image, but context menu item does not appear on mp4 video

[ZipFile]

Icon in address bar appears on the post pages, not direct links. But I think it kinda makes sense to enable it for direct links too, because in Chrome it is always enabled - should unify behavior across browsers. Supporting extra pages looks doable too. I'll try to do something once I have free time.

Also, missing context menu for videos is intentional. Every website implements players differently - it's pain in the ass to extract proper direct URLs (if even possible at all). It's unlikely I'll be adding it myself, but PRs are welcome.

[hdk5]

mp4 from fantia make up a large part of mp4 files on danbooru that are not sourced from twitter.

Since the address you get redirected to after clicking "download" is already a direct video url that is played in browser using its default player, and that is just works when you manually paste it in the upload form, so what is effectively needs to be done is passing the correct ref, I ask you to reconsider the last part.

[ZipFile]

Took a closer look. So far does not look as trivial as I though.

1. This one can be solved by injecting content script. It will add some friction communicating with a page, but still doable.
2. See pt.3 below. Essentially the same situation.
3. I'm not sure if it would be possible to do with minimal intervention/sniffing traffic. There are no direct URLs for video downloads. When you click a link you'll get redirected to the signed URL. Even if Add extension to context menu when right-clicking links #5 is implemented, this won't help, unless Danbooru somehow figure out how to "become a fan" to get a signed URL. You can't inject content script in between download button click and actual download start, so solution from pt.1 won't cut. Simulating click and doing request on behalf of the user would be kinda troublesome too - in Chrome it is straight up impossible because there is no info about exact element being rclicked, in Firefox isolation will probably be an issue (need to find a way how to pass auth credentials to the browser extension). One of the remaining options is to go nuclear and inspect the traffic (DevTools API is accessible from extension). Another one is to keep track of browsing history + injecting more content scripts to extract metadata to link pages with direct links. Either option will definitely make getting approved at AMO/CWS troublesome, not to mention this would be quite different workflow than simple rclick -> upload.

I have an idea how to do pt.1, solution should also work for stuff like https://i.redd.it/5zwrzdhjuco61.jpg where you get redirected to https://www.reddit.com/media?url=* which magically contains link to the original post (IIRC something similar is possible with Tumblr, but not guaranteed to have link to the original post). But pt.2 and pt.3 I'm not doing, I want to keep this extension lightweight.

[hdk5]

unless Danbooru somehow figure out how to "become a fan" to get a signed URL

I don't really get this part. If I have a signed url (after clicking download), I can download the file from it anywhere - be it same browser, separate browser, curl, or by feeding it to danbooru upload form. There is no need for danbooru server to subscribe to the artist. The only annoying part of this workflow is having to manually fix the "bad link" - due to lack of ref.

The rest - I don't understand at all, as I'm not familiar with the webextension api.

In any case, at first glance it looks like pt.2 and pt.3 are trivial to implement with a simple fantia-specific tampermonkey userscript. I'll work on it by myself.

[ZipFile]

When you click a context menu option, extension receives values of linkUrl (href attribute) and srcUrl (src attribute). If linkUrl is a known URL (one that toggle page action icon) it is used as ref param. If linkUrl is not available - current page URL is used. Legacy bookmarklet way of extracting referrer does not work in browser extension too, so not an option.

Here's the code:

upload-to-danbooru/src/refererGetter.js

Lines 17 to 27 in c9bfddf

	fromOnClickData(info) {
	if (info.srcUrl === info.pageUrl) {
	return info.frameUrl ? info.frameUrl : info.srcUrl;
	}
	if (info.linkUrl && this.refererRegex.test(info.linkUrl)) {
	return info.linkUrl;
	}
	return info.pageUrl;
	}

Example:

• pageUrl is https://fantia.jp/posts/XXX
• linkUrl is https://fantia.jp/posts/XXX/album_image?query=...
• srcUrl is https://cc.fantia.jp/uploads/album_image/file/XXX/main_UUID4.jpg?Key-Pair-Id=...&Policy=...&Signature=... - a signed sample/thumbnail.

This is what extension receives. None of this data is useful, since we're not uploading samples to Danbooru. Exactly the same happens if you enable context menu for regular links, but with different linkUrl (https://fantia.jp/posts/XXX/download/YYY) and missing srcUrl (which is useless anyway).

In order to receive original image, you have to actually follow linkUrl, which gets you HTTP 302 redirect to https://cc.fantia.jp/uploads/album_image/file/XXX/UUID4.jpg?Key-Pair-Id=...&Policy=...&Signature=... (note the absence of main_) with completely different signature (you cannot transplant signature from sample to original). Last time I checked, you cannot simply perform fetch from the extension with auth credentials of the page, so wrestling with content scripts and requesting extra host permissions are needed. Tampermonkey already have elevated permissions for every host at all times, but our extension has bare-minimmum temporary permissions for the current tab only. So userscript sound like a better idea security-wise.

[hdk5]

I ended up making the userscript for myself.
You may close the issue, as what is written above doesn't personally bother me anymore.