Front-end resource service cross-domain problem nginx chapter

Problem Description

1. First let's look at a picture

2. From the figure, we can clearly see that the "Cross-Origin" cross-domain problem will be reported when the http-requested site accesses the https resource. Why there is such an error, it is because of the "same-origin policy" problem. . . blablabla...

3. How to solve this problem in turn

 

problem solved

1. Let's look at the error message again. There is a section in the error message that says "Access-Control-Allow-Origin" header. From this, we can see whether it will be enough to add header on the server side?

2. Following this idea, the following sentence is added to the nginx configuration:

      add_header 'Access-Control-Allow-Origin' '*';

      as the picture shows:

 

3. After restarting, other content is good (for example, css files, etc.) and there is still a problem with the font (font) file, as shown in the figure:

 

 

 

 

why is that……! The Context-Type of the font file is "text/html"! ! ! And there is no Access-Control-Allow-Origin like anything else:*

 

4. So, continue to add such a sentence (as shown in the figure), specify the eot, ttf, woff font files to force the header information

5. I feel that everything will be fine in this way, wrong, wrong, wrong... I said important things three times (this place is a huge pit, I wasted a long time in the place to be said below, but it was finally solved, no Inked, let's move on...)

 

 

6. Suddenly found, oh, is it because I didn't add mime.types? (This must be added, because it determines the Content-Type of the file) This should be remembered earlier... blablabla... Hurry up and come back to see...

So I added three lines:

application/x-font-woff woff woff2; 
font/ttf ttf; 
font/opentype otf;

[Delete application/font-woff woff; delete this line (mime.types line 27), otherwise a duplicate warning will be reported]

7. Restart again and see again!

Oh, My God still does. . .

 

8. Take out the killer tool and check the log.

Found a fatal problem

 

Brother, why do you go to the $NGINX_HOME/html directory to find it? Shouldn't you find it from /www/xinghuo-img? (⊙o⊙)…

(Narrator: Who told you that "location /" and "location ~" will share the root of one of them...  

Okay I'm sorry.

 

9. So, I also added a root to "location ~" :)

10. "Last" restart, test, get it! as the picture shows:

postscript

1. I learned about the "same-origin policy" from the books on security testing before, and today I have seen and practiced the solution of cross-domain problems. Get up! Benefit a lot!

2. In fact, the last configuration file can be modified (as shown in the figure), I tentatively think that a root global variable can be set, hehe.

3. Still have to continue to study and study...fighting.

4. It tortured me from two to four o'clock... but it was resolved smoothly. Record it so that you don't have to step on the pit again in the future, thank you! blablabla...

5. It is very important, very important, very important to check the log in time when encountering a problem...

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325457280&siteId=291194637