nginx 解决跨域问题——(CORS)

跨域前世今生

跨域是一种安全机制。 在开发阶段与上线前就必须提前考虑到的安全问题并且采取合适的手段去避免这个问题带来的程序错误。
![aHR0cDovL2ZpbGUubWljcm9hbnN3ZXIuY24vYmxvZ181M18xLnBuZw.png](https://img-blog.csdnimg.cn/img_convert/1803660cf39d7222197f9bd7ae587575.png#averageHue=#f5dbdb&clientId=u5a77c99e-8b88-4&crop=0&crop=0&crop=1&crop=1&from=drop&id=u75149e36&margin=[object Object]&name=aHR0cDovL2ZpbGUubWljcm9hbnN3ZXIuY24vYmxvZ181M18xLnBuZw.png&originHeight=50&originWidth=731&originalType=binary&ratio=1&rotation=0&showTitle=false&size=16741&status=done&style=none&taskId=u87fb9500-7ae6-4758-969c-3a0efc9017b&title=)
跨域并不会阻止请求的发出,也不会阻止请求的接受,跨域是浏览器为了保护当前页面,你的请求得到了响应,浏览器不会把响应的数据交给页面上的回调,取而代之的是去提示你这是一个跨域数据。

常见跨域解决方案

只简述的说明,具体可以面向搜索引擎编程

反向代理

反向代理服务器位于用户与目标服务器之间,但是对于用户而言,反向代理服务器就相当于目标服务器,即用户直接访问反向代理服务器就可以获得目标服务器的资源。同时,用户不需要知道目标服务器的地址,也无须在用户端作任何设定。反向代理服务器通常可用来作为Web加速,即使用反向代理作为Web服务器的前置机来降低网络和服务器的负载,提高访问效率。
nginx 解决跨域问题——(CORS)_第1张图片

拿比较常见的web服务器来说配置如下

server{
    listen 80;
    server_name 127.0.0.1;
  	# 前端静态存放
    root /data/www/test1;
  	# 接口前缀
    location ~ ^/api {
        proxy_pass http://www.sdmtech.cn;
    }
 }

JSONP

SONP(JSON with Padding)是JSON的一种“使用模式”,可用于解决主流浏览器的跨域数据访问的问题。由于同源策略,一般来说位于 server1.example.com 的网页无法与不是 server1.example.com的服务器沟通,而 HTML 的

目前使用较多的场景在于三方SDK与服务器通信,其他时候使用频率不是很高,使用较多的是下面要讲的CORS

CORS

跨源资源共享(CORS,或通俗地译为跨域资源共享)是一种基于 HTTP 头的机制,该机制通过允许服务器标示除了它自己以外的其它源(域、协议和端口),使得浏览器允许这些 origin 访问加载自己的资源。跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求,该机制通过浏览器发起一个到服务器托管的跨源资源的“预检”请求。在预检中,浏览器发送的头中标示有 HTTP 方法和真实请求中会用到的头。
跨源 HTTP 请求的一个例子:运行在 https://domain-a.com 的 JavaScript 代码使用 XMLHttpRequest 来发起一个到 https://domain-b.com/data.json 的请求。
出于安全性,浏览器限制脚本内发起的跨源 HTTP 请求。例如,XMLHttpRequest 和 Fetch API 遵循同源策略。这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源,除非响应报文包含了正确 CORS 响应头。

相关解析

Access-Control-Allow-Origin

响应标头指定了该响应的资源是否被允许与给定的来源(origin)共享。

语法
Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null

Access-Control-Allow-Headers

响应首部 Access-Control-Allow-Headers 用于 preflight request(预检请求)中,列出了将会在正式请求的Access-Control-Request-Headers 字段中出现的首部信息。

语法
Access-Control-Allow-Headers: <header-name>[, <header-name>]*
Access-Control-Allow-Headers: *

Access-Control-Allow-Methods

响应首部 Access-Control-Allow-Methods 在对 preflight request.(预检请求)的应答中明确了客户端所要访问的资源允许使用的方法或方法列表。

语法
Access-Control-Allow-Methods: <method>, <method>, ...

NGINX配置解析

此种配置是 NGINX 流量转发到服务中

server{
    listen 80;
    server_name server1.example.com;
    location ~ .*$  {
      	# 允许所有源 并且总是
        add_header Access-Control-Allow-Origin '*' always;
      	# 允许通过所有header
        add_header Access-Control-Allow-Headers '*';
      	# 允许通过所有的方法
        add_header Access-Control-Allow-Methods '*';
      	# 响应头表示是对请求的响应暴露给页面
        add_header Access-Control-Allow-Credentials 'true';
      	# 如果请求为 OPTIONS 返回204状态码
        if ($request_method = 'OPTIONS') {
            return 204;
        }
        .......
    }
}

你可能感兴趣的:(杂项,nginx,服务器,前端)