nginx跨域请求Access-Control-Allow-Origin

前言

当出现403跨域错误的时候 No ‘Access-Control-Allow-Origin’ header is present on the requested resource,需要给Nginx服务器配置响应的header参数:

一、 解决方案

只需要在Nginx的配置文件中配置以下参数:

location / { 
 add_header Access-Control-Allow-Origin *;
 add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';
 add_header Access-Control-Allow-Headers 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization';

 if ($request_method = 'OPTIONS') {
  return 204;
 }
}

上面配置代码即可解决问题了。一般而言只需要配置Access-Control-Allow-Origin *

二、 解释

  1. Access-Control-Allow-Origin

服务器默认是不被允许跨域的。给Nginx服务器配置Access-Control-Allow-Origin *后,表示服务器可以接受所有的请求源(Origin),即接受所有跨域的请求。

  1. Access-Control-Allow-Headers 是为了防止出现以下错误:

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

这个错误表示当前请求Content-Type的值不被支持。其实是我们发起了"application/json"的类型请求导致的。这里涉及到一个概念:预检请求(preflight request),请看下面"预检请求"的介绍。

  1. Access-Control-Allow-Methods 是为了防止出现以下错误:

Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

  1. 给OPTIONS 添加 204的返回,是为了处理在发送POST请求时Nginx依然拒绝访问的错误

发送"预检请求"时,需要用到方法 OPTIONS ,所以服务器需要允许该方法。

三、 预检请求(preflight request)

其实上面的配置涉及到了一个W3C标准:CROS,全称是跨域资源共享 (Cross-origin resource sharing),它的提出就是为了解决跨域请求的。

跨域资源共享(CORS)标准新增了一组 HTTP 首部字段,允许服务器声明哪些源站有权限访问哪些资源。另外,规范要求,对那些可能对服务器数据产生副作用的HTTP 请求方法(特别是 GET 以外的 HTTP 请求,或者搭配某些 MIME 类型的 POST 请求),浏览器必须首先使用 OPTIONS 方法发起一个预检请求(preflight request),从而获知服务端是否允许该跨域请求。服务器确认允许之后,才发起实际的 HTTP 请求。在预检请求的返回中,服务器端也可以通知客户端,是否需要携带身份凭证(包括 Cookies 和 HTTP 认证相关数据)。

其实Content-Type字段的类型为application/json的请求就是上面所说的搭配某些 MIME 类型的 POST 请求,CORS规定,Content-Type不属于以下MIME类型的,都属于预检请求:

application/x-www-form-urlencoded
multipart/form-data
text/plain

所以 application/json的请求 会在正式通信之前,增加一次"预检"请求,这次"预检"请求会带上头部信息 Access-Control-Request-Headers: Content-Type

OPTIONS /api/test HTTP/1.1
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type
... 省略了一些

服务器回应时,返回的头部信息如果不包含Access-Control-Allow-Headers: Content-Type则表示不接受非默认的的Content-Type。即出现以下错误:

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

### Nginx 配置解决问题 为了使Nginx能够处理来自不同源的HTTP请求,即解决CORS(Cross-Origin Resource Sharing)问题,在Nginx配置文件中添加特定的响应头是必要的措施之一。对于`Access-Control-Allow-Origin`头部来说,可以通过如下方式来设置: #### 方法一:全局配置允许所有名访问 如果目标是在开发环境中快速验证功能或是确实需要开放给任何来源站点访问资源,则可以在http、server或location上下文中加入以下指令[^1]。 ```nginx add_header Access-Control-Allow-Origin *; ``` 然而需要注意的是,这种做法存在安全隐患,因为它意味着所有的外部网站都可以无条件地向该服务发起请求并获取数据。 #### 方法二:指定单个或多个可信任的名 更安全的做法是指定具体的可信源站地址作为`Access-Control-Allow-Origin`的值。这可以有效防止未经授权的第三方网站滥用API接口。 ```nginx add_header Access-Control-Allow-Origin http://example.com; # 或者支持多名时使用正则表达式匹配 if ($http_origin ~* (http://|https://)(www\.)?(domain1\.com|domain2\.com)) { add_header Access-Control-Allow-Origin $http_origin; } ``` 除了上述基本配置外,有时还需要额外声明其他相关联的CORS头部信息以便更好地控制资源共享行为,比如允许哪些方法(`GET`, `POST`)以及自定义请求头字段等[^3]。 ```nginx add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; add_header Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept"; ``` 特别注意针对预检请求(Preflight Request),也就是浏览器发送OPTIONS类型的探测性请求之前端会先询问服务器是否同意实际操作所携带的方法和headers组合;因此建议为这类特殊场景也做好相应准备。 最后提醒一点关于字体文件之类的静态资源,默认情况下它们不会自动带上这些CORS相关的头部信息,所以如果你的应用涉及到此类资产加载失败的情况,请记得单独为其路径下的资源加上合适的cross-origin属性或者调整Nginx配置以确保正常工作[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

iningwei

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值