1 nginx跨越
跨源资源共享(CORS)是一种机制,它使用额外的HTTP标头让用户代理获得访问来自不同来域的服务器上选定资源的权限,而不是使用当前正在使用的站点。用户代理在请求来自与当前文档不同的域,协议或端口的资源时,会发出跨源HTTP请求。
产生跨域的原因?
*出于安全原因,浏览器限制从脚本内发起的跨域HTTP请求。例如,XMLHttpRequest与提取API遵循同域策略。这意味着使用这些API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源,除非使用CORS头文件。
*浏览器为了安全问题一般都限制了跨域访问,也就是不允许跨域请求资源。
*同ip (或domain),同端口,同协议视为同一个域,一个域内的脚本仅仅具有本域内的权限,可以理解为本域脚本只能读写本域内的资源,而无法访问其它域的资源。这种安全限制称为同源策略。
*现代浏览器在安全性和可用性之间选择了一个平衡点。在遵循同源策略的基础上,选择性地为同源策略“开放了后门”。例如img script style等标签,都允许垮域引用资源,然而,你也只能是引用这些资源而已,并不能读取这些资源的内容。
同域策略的限制
- Cookie,LocalStorage和IndexDB无法读取
- DOM和js对象无法获取
- AJAX请求无法发送
常见的跨域场景
URL | 说明 | 是否允许通信 |
---|---|---|
http:/lwww.a.com/a.js ==> http:/lwww.a.com/b.js | 同一域名下 | 允许 |
http://www.a.com/lab/a.js ==> http://www.a.com/script/b.js | 同一域名下不同文件夹 | 允许 |
http:/www.a.com:8000/a.js ==> http://www.a.com/b.js | 同一域名,不同端口 | 不允许 |
http://www.a.com/a.js ==> https://www.a.com/b.js | 同一域名,不同协议 | 不允许 |
http://www.a.com/a.js ==> http://70.32.92.74/b.js | 域名和域名对应ip | 不允许 |
http://www.a.com/a.js ==> http://script.a.com/b.js | 主域相同,子域不同 | 不允许 |
http:/www.a.com/a.js ==> http://a.com/b.js | 同一域名,不同二级域名(同上)不允许(cookie这种情况下也不允许访问) | 不允许 |
http://www.cnblogs.com/a.js ==> http://www.a.com/b.js | 不同域名 | 不允许 |
跨域的解决方案
- 通过jsonp跨域
- document.domain + iframe跨域
- location.hash + iframe
- window.name + iframe跨域
- postMessage跨域
- 跨域资源共享(CORS)
- nginx代理跨域
- nodejs中间件代理跨域
- WebSocket协议跨域
1.1 nginx的正向代理与反向代理
正向代理:代理位于网站和客户端中间,客户端无法访问某网站,就将请求发送给代理服务器,代理从网站取回来再发送给客户端,网站并不知道为谁提供服务
反向代理:客户端访问某网站的一个页面,但是网站并没有,就偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户,用户不知道真正提供服务的是谁
nginx是如何通过反向代理解决跨域的
对于浏览器来说,访问的就是同源服务器上的一个url。而nginx通过检测url前缀,把http请求转发到后面真实的物理服务器。并通过rewrite命令把前缀再去掉。这样真实的服务器就可以正确处理请求,并且并不知道这个请求是来自代理服务器的。
简单说,nginx服务器欺骗了浏览器,让它认为这是同源调用,从而解决了浏览器的跨域问题。又通过重写url,欺骗了真实的服务器,让它以为这个http请求是直接来自与用户浏览器的。
server
{
listen 80;
server_name www.blogs.com;
root /www/blog;
index index.html index.php;
location /api/ {
proxy_pass http://www.blogs-s.com:8080/api/;
}
}
当客户端请求http://www.blogs.com/api/index.php时,通过nginx将请求发送到 http://www.blogs-s.com:8080/api/ 进行处理。
网友评论