Some thoughts on the IMG 403 Forbidden

Web pages often need to display images to the user to see, to the site itself, some pictures are from the local image server, but once the number of more, disk space is a problem.

So sometimes I want to show the image of other websites, and show the pictures of other websites directly on my website. But not all of the external network image can be directly connected to display.

In many cases, Web site developers will encounter 403 forbidden problems. For example, to display a picture from IMDB

Local localhost debug can be fully displayed, but after you deploy the Web site to the server you will encounter such errors
The strange thing is to access the picture through the browser connection, the picture is normal display out.
What is this again? In fact, Referer is automatically added by the browser, but there are exceptions such as
1. Direct access via browser
2. Use Location.href or location.replace in front of the web
3. Using encryption protocols such as HTTPS
This is the hotlinking hotlinking problem, which can be done by configuring the Web server side to implement this anti-hotlinking behavior.
Why do websites like IMDB have to do Anti hotlinking anti-hotlinking things?
The issue of copyright is one aspect.
On the other hand can be called bandwidth Theft, when users visit the IMDB page, IMDB needs to bandwidth transfer data, and bandwidth is one of the costs of the site.
Like no one is willing to secretly plug the electrical appliance into your socket, secretly use your electricity, and you go to bear all the costs.
How do I configure the server implementation anti hotlinking?
Take ASP. NET MVC as an example
You can add actionfilter to the controller or add IHttpHandler to handle antihotlinking
The core is urlreferrer.
HttpRequest has a field urlreferrer:
This field indicates which URL accessed the server in the same way as the above IMG src.
The visitor's domain var refdomain = request.urlreferrer.host;//The current website domain var serverdomain = Request.Url.Host;
Finally, you can determine anti hotlinking's strategy by judging whether it comes from the same domain.
Alternatively, you can configure Urlrewrite in Web. config to implement the
<rewrite><rules>  <rule name= "Anti hotlinking rule for Image" enabled= "true" stopprocessing= "true" >  <match url= ". *\. ( gif|jpg|png) $ "/>  <conditions>    <add input=" {http_referer} "negate=" true "pattern=" ^$ "/>    <add input= "{http_referer}" negate= "true" pattern= "http://www.yourwebsite.com/.*"/> <add input=    " {http_referer} "negate=" true "pattern=" http://yourwebsite.com/.* "/>  </conditions>  <action Type= "Rewrite" url= "/images/anti-hotlinking.png"/></rule></rules></rewrite>
What if a site user wants to see a picture or video that can't be displayed?
Here we recommend a Chrome plugin anti-anti-hotlinking
After installation, you can see pictures that are not displayed.
I did not study the plug-in carefully, it may be through download to solve the hotlinking problem, it may be through the chrome hijacking request modification Urlreferer implementation.
Are there any workarounds for Web developers?
1. Download the image of the external network to the server side and convert it to base64 finally to the IMG tag.
        public static string ImageToBase64 (Stream imagestream, imageformat format)        {            using (System.Drawing.Image Image = System.Drawing.Image.FromStream (ImageStream))            {                using (MemoryStream stream = new MemoryStream ())                {                    image. Save (stream, format);                    var result = System.Convert.ToBase64String (stream. ToArray ());                    return result;}}        }
2. Use the Refererkiller JavaScript plugin to bypass Urlreferer
Referrerkiller.imagehtml ("Fakeweb/fakeimage.png"); Returns the HTML string of the IMG that can be displayed
Referrerkiller.imagehtml ("Fakeweb/fakeimage.png"); Returns the DOM node of the IMG that can be displayed
In fact, these two functions are the same thing, can be picked up convenient use.
This approach solves the hotlinking problem in fact the principle is very simple, in the web such as <script src= "Differentdomain/fake.js" > </script>
Loading JS is an issue with no cross-domain access.
Referrerkiller generates an IFRAME dynamically and adds an IMG tag within the IFRAME. Using SRC-loaded features to put the code in SRC, you can remove the referer.
So Referrerkiller.imagehtml returned an IFRAME that could display the image.
Some thoughts on the IMG 403 Forbidden