在 ajax 跨域请求中携带 cookie 做身份认证
时间 2016-06-04 21:33:00 Secbone's Blog
好吧,一如既往的短篇记录性文章,记下坑供查阅
原因大概是这样的,公司有很多内网的服务系统,同属于同一个主域,但是是不同的子域,然后呢,当在一个系统需要调用另一个系统的时候,就会出现跨域的问题。所以呢,我们打算写一个通用代理程序来做中转,然后呢,先简单贴一下代码吧
var server = http.createServer(function(request, response) {
...
var options = {
hostname: address.hostname,
port: address.port || 80,
path: address.path,
method: request.method,
headers: request.headers,
};
options.headers.host = address.host;
var proxy = http.request(options, function(res) {
for(var key in res.headers) {
response.setHeader(key, res.headers[key]);
}
response.setHeader("Access-Control-Allow-Origin", "*");
res.pipe(response);
});
request.pipe(proxy);
});
var server = http.createServer(function(request, response) {
...
var options = {
hostname: address.hostname,
port: address.port || 80,
path: address.path,
method: request.method,
headers: request.headers,
};
options.headers.host = address.host;
var proxy = http.request(options, function(res) {
for(var key in res.headers) {
response.setHeader(key, res.headers[key]);
}
response.setHeader("Access-Control-Allow-Origin", "*");
res.pipe(response);
});
request.pipe(proxy);
});
嗯嗯,大概就是这样的
但是,马上我们就发现了问题,是的,事情总不会这么顺利。接下来我们发现,因为这个代理 Server 和 web 也不是同一个子域,所以虽然我们添加了允许跨域的头,但是会发现,发送到后端的 POST 跨域请求并没有携带 cookie 信息,然后也就没有办法得到另一个服务系统的认证。
OK,当我们手动在 ajax 请求中把 cookie 添加到头信息中的时候,像下面这样
$.ajax({
...
headers: {"Cookie": document.cookie},
...
});
$.ajax({
...
headers: {"Cookie": document.cookie},
...
});
但是浏览器会提示这是一个不安全的操作,然后就。。。。 华丽丽的拒绝掉了
withCredentials
$.ajax({
...
xhrFields: {
withCredentials: true
}
});
$.ajax({
...
xhrFields: {
withCredentials: true
}
});
然后呢,我们需要在我们的 Server 返回的时候加上一条头信息
response.setHeader("Access-Control-Allow-Credentials", true);
Access-Control-Allow-Origin
不能用 *
听起来好像很合理,如果你想用一个域的 cookie 来认证的话,就指定一下这个域,很合理的要求,那么,当我们的想写一个通用的代理程序,希望任何一个域名都可以通过它的 cookie 来认证它要代理的 API 接口时,要怎么办?
听上去好像不是一个合理的需求,当时貌似,还真的有办法,就是再返回的时候,把请求的域填写进头信息里,就是谁访问我,我允许谁,代码大概就是这样的
response.setHeader("Access-Control-Allow-Credentials", true);
response.setHeader("Access-Control-Allow-Origin", request.headers.origin);
嗯嗯,就是这样啦,虽然感觉最后并不是一个很正确的方式,但是也算是解决了我们奇葩的需求了