跨域访问,或者说JavaScript的跨域访问问题,是浏览器出于安全考虑而设置的一个限制,即同源策略。当来自于A网站的页面中的JavaScript代码希望访问B网站的时候,浏览器会拒绝该访问,因为A、B两个网站是属于不同的域。
在实际应用中,经常会有跨域访问的需求,比如用户的网站
www.a.com,后端使用了OSS。在网页中提供了使用JavaScript实现的上传功能,但是在该页面中,只能向
www.a.com发送请求,向其他网站发送的请求都会被浏览器拒绝。这样就导致用户上传的数据必须从
www.a.com中转。如果设置了跨域访问的话,用户就可以直接上传到OSS而无需从
www.a.com中转。
跨域资源共享的实现
跨域资源共享(Cross-Origin Resource Sharing),简称CORS,是HTML5提供的标准跨域解决方案,OSS支持CORS标准来实现跨域访问。具体的CORS规则可以参考
W3C CORS规范。其实现如下:
- CORS通过HTTP请求中附带Origin的Header来表明自己来源域,比如上面那个例子,Origin的Header就是www.a.com。
- 服务器端接收到这个请求之后,会根据一定的规则判断是否允许该来源域的请求。如果允许的话,服务器在返回的响应中会附带上Access-Control-Allow-Origin这个Header,内容为www.a.com来表示允许该次跨域访问。如果服务器允许所有的跨域请求,将Access-Control-Allow-Origin的Header设置为*即可,
- 浏览器根据是否返回了对应的Header来决定该跨域请求是否成功,如果没有附加对应的Header,浏览器将会拦截该请求。如果是非简单请求,浏览器会先发送一个OPTIONS请求来获取服务器的CORS配置,如果服务器不支持接下来的操作,浏览器也会拦截接下来的请求。
OSS提供了CORS规则的配置从而根据需求允许或者拒绝相应的跨域请求。该规则是配置在Bucket级别的。详情可以参考
PutBucketCORS。
这里有几个要点:
- CORS相关的Header附加等都是浏览器自动完成的,用户不需要有任何额外的操作。CORS操作也只在浏览器环境下有意义。
- CORS请求的通过与否和OSS的身份验证是完全独立的,即OSS的CORS规则仅仅是用来决定是否附加CORS相关的Header的一个规则。是否拦截该请求完全由浏览器决定。
- 使用跨域请求的时候需要关注浏览器是否开启了Cache功能。当运行在同一个浏览器上分别来源于www.a.com和www.b.com的两个页面都同时请求同一个跨域资源的时候,如果www.a.com的请求先到达服务器,服务器将资源带上Access-Control-Allow-Origin的Header为www.a.com返回给用户。这个时候www.b.com又发起了请求,浏览器会将Cache的上一次请求返回给用户,此时Header的内容和CORS的要求不匹配,就会导致后面的请求失败。
功能使用参考