angularjs跨域post解决方案

最新推荐文章于 2021-08-05 21:19:25 发布

swimming_in_it_

最新推荐文章于 2021-08-05 21:19:25 发布

阅读量520

点赞数

分类专栏：前端插件+框架 nodejs 文章标签： angularJs post 跨域 options

nodejs 同时被 2 个专栏收录

72 篇文章 0 订阅

订阅专栏

前端插件+框架

11 篇文章 0 订阅

订阅专栏

前端同学李雷和后台同学韩梅梅分别在自己电脑上进行开发，后台接口写好的时候，李雷改动完就把前端代码上传到gitlab，然后在测试机上从gitlab上拉下来，然后在测试机上移动最新代码，最后回到本机刷新页面。有时候碰到网速不好的情况传个git传了半天，或者李雷刚上传完发现少写了一个单词，加上再传上一看尼玛单词又写错了。对于实时需要改动代码的李雷同学而言

另外一种方案是李雷和韩梅梅分别在自己电脑上进行开发，韩梅梅写完一个接口，李雷马上在本地调用接口进行请求，有需要改动的地方，改完按下F5，看到的就是最新的。perfect！

既然这样，为什么不选用方便快捷的后者呢。后者会遇到哪些问题？这里就要好好扯一下跨域了。

什么是跨域？

浏览器的同源策略限制了一个源（origin）中加载文本或脚本与来自其它源（origin）中资源的交互方式。如果两个页面的协议（protocol）、端口（如果指定）、和主机任一不相同，则他们就不是同源的，在他们之间进行请求则认为是跨域。

跨域的解决办法

跨域的解决方案主要有JSONP、改变domain、CORS等等，因为项目适用于使用CORS，所以我们在项目中使用此方案，这里也只讨论CORS。

CORS

CORS（Cross-Origin Resource Sharing）跨域资源共享，定义了必须在访问跨域资源时，浏览器与服务器应该如何沟通。CORS背后的基本思想就是使用自定义的HTTP头部让浏览器与服务器进行沟通，从而决定请求或响应是应该成功还是失败。
换句话说，就是服务器在响应头里设置好允许哪些地址访问（通过Access-Control-Allow-Origin设置），当浏览器收到服务端响应时，查看这个字段，如果包含请求方的地址或设置为了*，则允许此次跨域。

那么，我们在项目里只需要在服务端设置好Access-Control-Allow-Origin头，即可允许前端同学发起的请求跨域。

对于php而言，即设置:

header('Access-Control-Allow-Origin: *');

这样就能愉快的跨域了！

看到这里的时候，国存和昕晨一定是这个表情

国存：真的假的，那跟你调试的时候怎么老是收不到你的数据，前面还多的一个OPTIONS请求是什么狗？
昕晨：我用jQuery明明就请求到数据，你用angularJS就不行，你这不讲道理。

讲道理的话是应该没有跨域的问题了，但是！这里牵扯到了跨域的其他限制以及jQuery和angularJS的Ajax请求的差异！

下面来详细说明这些坑：

jQuery和angularJS的Ajax请求的差异

一、为什么有时候用jQuery请求的到数据，用angularJS请求就拿不到？

这在于jQuery和angularJS序列化和传输数据有差异，通过jQuery请求时，请求头的Content-Type为Content-Type: x-www-form-urlencoded，即类似name=lilei&age=20，而angularJS使用的是Content-Type: application/json，类似{ "name": "lilei", "age": "20" }

而在php里，我们一开始是通过$_POST方法来获取参数的，在php官网上对$_POST的文档里，我在下面的User Contributed Notes中找到这么一段：
QQ图片20151031144456.png

那么也就是说，angularJS的Content-Type: application/json是不能通过$_POST方法获取的。在Make AngularJS $http service behave like jQuery.ajax()这篇文章里面，作者也提到

AngularJS, however, transmits data using Content-Type: application/json and{ "foo": "bar", "baz": "moe" } JSON serialization, which unfortunately some Web server languages—notably PHP—do not unserialize natively.

作者也提到了解决办法：
1. 在客户端改变angularJS默认传输格式为Content-Type: x-www-form-urlencoded，并改变传输数据的格式。
2. 在php中使用$params = json_decode(file_get_contents('php://input'));来读取输入流。
（具体见本文末中的原文链接）

二、为什么用angularJS进行POST请求之前还发送了一个OPTIONS请求

在MDN上对HTTP访问控制中有这样一段：

跨源资源共享标准通过新增一系列 HTTP 头，让服务器能声明那些来源可以通过浏览器访问该服务器上的资源。另外，对那些会对服务器数据造成破坏性影响的 HTTP 请求方法（特别是 GET 以外的 HTTP 方法，或者搭配某些MIME类型的POST请求），标准强烈要求浏览器必须先以 OPTIONS 请求方式发送一个预请求(preflight request)，从而获知服务器端对跨源请求所支持 HTTP 方法。在确认服务器允许该跨源请求的情况下，以实际的 HTTP 请求方法发送那个真正的请求。服务器端也可以通知客户端，是不是需要随同请求一起发送信用信息（包括 Cookies 和 HTTP 认证相关数据）。

也就是说，当进行POST请求时，浏览器应该先发送OPTIONS请求，以判断服务器接受哪些跨源请求的方法。

那为什么jQuery没有发出OPTIONS请求呢？这是因为jQuery发出的请求是一个简单请求，所谓的简单，是指：

只使用 GET, HEAD 或者 POST 请求方法。如果使用 POST 向服务器端传送数据，则数据类型(Content-Type)只能是 application/x-www-form-urlencoded, multipart/form-data 或text/plain中的一种。
不会使用自定义请求头（类似于 X-Modified 这种）。

jQuery的请求幸运的成为了一个简单请求，而很不幸的，angularJS的请求是一个复杂请求。

部分CORS请求并不是直接就可以向服务器发送的，不能直接发的这部分请求我们就称为复杂请求

WTF？？？什么是复杂请求呢

It uses methods other than GET, HEAD or POST. Also, if POST is used to send request data with a Content-Type other than application/x-www-form-urlencoded,multipart/form-data, or text/plain, e.g. if the POST request sends an XML payload to the server using application/xml or text/xml, then the request is preflighted.
It sets custom headers in the request (e.g. the request uses a header such as X-PINGOTHER)

然后，AngularJS就被干掉了。

三、为什么还要在服务端加上`Access-Control-Allow-Headers: Content-Type`

对于jQuery是不必加的，但是使用AngularJS必须要加。

来看一下AngularJS发送的OPTIONS 请求：

OPTIONS /index.php/accountmanager/list_all HTTP/1.1
Host: 10.170.202.246:2872
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost:9000
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://localhost:9000/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

这是使用angularJS进行请求时的预请求，可以看到里面有几个特别的请求头’Access-Control-Request-Method: POST’、Access-Control-Request-Headers: accept, content-type.
第一个头说明本次实际跨域请求方法是POST请求（告诉服务器：等会我就要发POST了），第二个头用来告诉服务器在实际请求时会携带的自定义头信息，可以看到自定义头信息里面竟然有一个content-type。这是因为application/json实际上不是浏览器原生支持的方法。所以服务器也需要设置我允许哪些自定义头信息，即Access-Control-Allow-Headers。

最后，言而总之，总而言之，跨域开发并不可怕，搞定这个问题开发速度翻一倍！不过跨域也有不足之处：只支持IE8以上。

（完）