The gitee image bed failed to load, let's reproduce the crime scene and the principle of anti-leech

This afternoon, some friends in the group and in the circle of friends reported that the pictures in the Gitee picture bed cannot be opened

In this article, I use https://gitee.com/Topcvan/js-notes-img/raw/master/%E5%AE%8F%E4%BB%BB%E5%8A%A1%E9%98%9F%E5%88%97.pngthis picture as an example to reproduce the incident.

anti-theft chain

I thought, this must be the sudden addition of the anti-theft chain, let's take a look at the principle of the anti-theft chain:

Referer refers to the address of the source page of the current request page, which is used to determine the access source of the current page. The image anti-theft chain replaces the image with the image of the prohibition sign by judging Refererwhether it is the target website.

Referer is actually referrera misspelling of the word

For example, in this gitee event, when all images on the gitee website are loaded, the browser will add the last request header to the image by default: referer: https://gitee.com/. On other websites, if the referer request header field carried is not the website of gitee, a placeholder image will be returned.

However, in general, the anti-leech image can be opened directly in the browser, because it will not carry the refererrequest header field when it is opened directly in the browser, and the anti-leech configuration will allow this.

If so, if you are on a personal website, you can configure all image requests without request header fields through the Referrer PolicyReferer to bypass the anti-leech settings .

<meta name="referrer" content="no-referrer">
复制代码

To this end, I made two web pages specially, and compared them according to the mdnice URL pictures that have been set up with anti-leech:

Added this header to successfully bypass anti-leech settings: vercel-api.shanyue.vercel.app/referrer
If this header is not added, the image is blocked by 403: vercel-api.shanyue.vercel.app/referrer/fo…

403

Oh yes, when you open two URLs at this time, remember to disable caching in the browser console : (PS: add a Vary: referer to prohibit such problems)

However, this doesn't work for gitee!

gitee's anti-leech measures

However, the anti-leech measures set by gitee are stricter:

The pictures in gitee will also undergo anti-leech processing if they do not carry the referer

For this, I did a controlled experiment based on the refererfield .

Directly request the image address through cURL , nothing is returned :

$ curl 'https://gitee.com/Topcvan/js-notes-img/raw/master/%E5%AE%8F%E4%BB%BB%E5%8A%A1%E9%98%9F%E5%88%97.png' \
  --compressed
复制代码

Directly request the image address through cURL, and carry the refererfield , there is content and return correctly :

$ curl 'https://gitee.com/Topcvan/js-notes-img/raw/master/%E5%AE%8F%E4%BB%BB%E5%8A%A1%E9%98%9F%E5%88%97.png' \
  -H 'Referer: https://gitee.com/' \
  --compressed
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
复制代码

Screenshot below:

Directly replace the src of an img in the official website with the personal gitee image address, and open it normally:

evaluate

It stands to reason that the anti-leech is also to avoid the large amount of misappropriation of pictures and other resources in the website, resulting in a huge server fee. But gitee has a better approach:

One month's notice in advance, smooth transition, and will not cause such a big repercussion
The anti-leech policy is too strict, and the pictures cannot be opened directly in the browser

Even like the Nuggets, add a watermark of your own in the lower right corner!