为什么会产生跨域
首先,跨域是针对客户端而言的,服务端是不存在跨域安全限制的。
由于浏览器同源策略(同一协议,同一域名,同一端口号)的限制,非同源下的请求,都会产生跨域问题。
JSONP
处理跨域的一种解决方案,那jsonp是如何突破同源策略限制实现跨域的呢
1.jsonp原理
在平时的开发工作中,不管是script标签的src还是img标签的src,或者说link标签的href都可以随意引用自其他域名下,并没有被通源策略所限制,通过chrome开发工具在network可以看到这些资源请求都是通过get请求实现的。所以jsonp就是通过动态创建script标签来实现跨域的
2.代码实现
<button id="btn">点击</button>
<script src="https://cdn.bootcss.com/jquery/3.3.1/jquery.min.js"></script>
<script>
$('#btn').click(function(){
var frame = document.createElement('script');
frame.src = 'http://localhost:8080/index?callback=func';
$('body').append(frame);
});
function func(res){
console.log('收到消息咯')
}
</script>
当点击button按钮时,添加一个<script>标签,用于发起跨域请求;注意看请求地址后面带了一个callback=func的参数;
func即是回调函数名称,传到后台,用于包裹数据。数据返回到前端后,就是func(result)的形式,因为是script脚本,所以自动调用func函数,而result就是func的参数。至此,算是跨域把数据请求回来了。
需要注意的是,callback参数定义的方法是需要前后端定义好的。其实jsonp的整个过程就类似于前端声明好一个函数,后端返回执行函数。执行函数参数中携带所需的数据
3.Jquery的jsonp实现
只需配置一个dataType:'jsonp',就可以发起一个跨域请求。jsonp指定服务器返回的数据类型为jsonp格式,可以看发起的请求路径,自动带了一个callback=xxx,xxx是jquery随机生成的一个回调函数名称。如果有success函数则默认success()作为回调函数。
当然也可以通过设置jsonpCallback参数自定义callback函数,将回调函数写在ajax外部
同时callback这个名称也可以改变,但是这个必须要服务端配合设置
<html>
<head>
<title>跨域测试</title>
<script src="js/jquery-1.7.2.js"></script>
<script>
function showData (data) {
console.info("调用showData");
var result = JSON.stringify(data);
$("#text").val(result);
}
$(document).ready(function () {
$("#btn").click(function () {
$.ajax({
url: "http://localhost:9090/student",
type: "GET",
dataType: "jsonp", //指定服务器返回的数据类型
jsonp: "theFunction", //将请求的callback参数名称修改为theFunction
jsonpCallback: "showData", //指定回调函数名称
success: function (data) {
console.info("调用success");
}
});
});
});
</script>
</head>
<body>
<input id="btn" type="button" value="跨域获取数据" />
<textarea id="text" style="width: 400px; height: 100px;"></textarea>
</body>
</html>
优缺点
优点:兼容性更好,在更加古老的浏览器中都可以运行,不需要XMLHttpRequest或ActiveX的支持;并且在请求完毕后可以通过调用callback的方式回传结果。
缺点:由其实现原理可以发现,只支持GET请求而不支持POST等其它类型的HTTP请求;它只支持跨域HTTP请求这种情况,并且也不能解决不同域的两个页面之间如何进行JavaScript调用的问题。
安全性问题
CSRF攻击
前端构造一个恶意页面,请求JSONP接口,收集服务端的敏感信息。如果JSONP接口还涉及一些敏感操作或信息(比如登录、删除等操作),那就更不安全了。
解决方法:验证JSONP的调用来源(Referer),服务端判断Referer是否是白名单,或者部署随机Token来防御。
XSS漏洞
不严谨的 content-type导致的 XSS 漏洞,想象一下 JSONP 就是你请求 http://a.com?callback=func
, 然后返回 func({ data })
,那假如请求 http://a.com?callback=<script>alert(1)</script>
不就返回 <script>alert(1)</script>({ data })
了吗,如果没有严格定义好 Content-Type( Content-Type: application/json ),再加上没有过滤 callback
参数,直接当 html 解析了,就是一个赤裸裸的 XSS 了。
解决方法:严格定义 Content-Type: application/json,然后严格过滤 callback
后的参数并且限制长度(进行字符转义,例如<换成<,>换成>)等,这样返回的脚本内容会变成文本格式,脚本将不会执行。