1993 迎来了 img 标签,这是 web 第一次迎来了资源加载
<img src="foo.jpg" />
<img src="http://somewhere.com/foo.jpg" />
1994
Set-Cookie: foo=bar
1995
<img src="http://somewhere.com/foo.jpg" />
<script src="http://somewhere.com/foo.js" ></script>
<iframe src="http://somewhere.com/foo.html" />
起初这样的设计会导致严重的问题:无论是网站,只要包含上面的标签都会携带 cookie 访问。
更不用说这样的请求了。
<form action="http://somewhere.com./submit"></form>
因此 http 通过 Origin 这个头来限制访问
1999
// XMLHttpRequest 的前身
new ActiveXObject('Microsoft.XMLHTTP');
2008
var req = new XMLHttpRequest()
req.addEventListener('load', loadListener);
req.open('GET', 'https://example.com/data.txt');
req.send();
const res = await fetch('http://example.com/data.txt', {
credentials: 'include',
});
现在我们已经使用这样方式请求,但是同样也要受限于服务器是否响应 (下面就是服务器为什么有的会响应)。
我们通过 access-control-allow-origin 来决定那些那资源可以被跨域访问,例如设置 access-control-allow-origin: * 允许所有资源可以被访问 。并且通过设置 credential 来决定是否携带 cookie 。
access-control-allow-credentials: true 决定是否允许你访问 cookie。但是同时你必须明确通过 access-control-allow-origin 指出跨域访问的网址。
这些头信息已经在我们通过浏览器发出的请求中设置好了,我们不需要特别关心。例如我们通过 <form> 发送时请求时, Content-Type 已经设置成例如 x-www-form-urlencoded 。
一个小知识点:你可以发送设置成 Content-type: text/plain 的 POST 请求。例如通过 <form> 来发送 email,只要保证了像 x-www-form-urlencoded 的空行间隔。
从一个网站跳到另外一个网站时,会有这个头信息
Referrer 不可靠,所以有了 Origin 这个头信息。Origin 会出现在跨域的请求中。
通常来说,我们限制了 access-control-allow-origin 网站就已经足够安全。
除了CORS 得GET 请求外,其他的GET 请求都不带 Origin。可以通过判断 Origin 得知这个是不是跨域的请求。
当我们不带 cookie 发出请求时,可能会引发很多问题。首先我们要知道什么情况 access-control-allow-origin: * 时是安全的 ,例如家中分布的IoT 设备,本地的请求。除此之外都可能引发CSRF 攻击。
例如通过图片追踪。当你访问 other.com 时,<img /> 会允许设置cookie 从而进行跟踪。
<!-- site: other.com -->
<img src="http://statics.com/user-avatar-a.png" />
设置 SameSite: Strict | Lax | None 。Lax 不允许 img、 iframe 、 AJAX 、 POST 表单携带 cookie (当前所在地站点是:other.com ) 。不过 Lax 允许<a>链接,预加载请求,GET 表单这3种情况的携带 cookie 。
Set-cookie: sessionid=1234567; SameSite=Lax; HttpOnly; Max-Age=3153600
SameSite: Strict 这会导致所有的跨域均不带 cookie ,例如在非github 的网站上跳转至 github 将不会携带 cookie ,此时 github 将显示未登录。
httponly:不能通过 javasript 获取 cookie
Cross-Origin-Resource-Policy: same-site 标记为 same-site 的资源只能从相同站点加载。
Cross-Origin-Resource-Policy 响应头会指示浏览器阻止对指定资源的无源跨域/跨站点请求。
在下面这个请求中加入 CORP 的头信息,图片将加载失败。
<!-- site: other.com -->
<img src="http://statics.com/user-avatar-a.png" />
Cross-Origin-Resource-Policy: same-site | same-origin |cross-origin
下面这个场景是无法通过同一个 cookie 处理,虽然你可以将 cookie 放在 html 的请求中。
<img src="http://example.com/secret.html" />
这个请求仍然会将 html 文件的请求放到进程中,来表示当前请求处理完成。这可能会引起某些问题。Meltdown and Spectre
Cross-Origin-Read-Blocking 阻止跨域的请求动作,同时跨域的返回也会被阻止。例如上面的请求,将不会进入浏览器的处理进程中。
请求在进入进程前,会注意mine type 如果是 nosniff (nosniff 将阻止浏览器针对 content-type的一些优化)。Chrome 浏览器针对 html 文件的请求并且不是跨域将会阻止。
CORB 是不头信息
Cross-Origin-Embedder-Policy: require-corp 文档只能从同一来源加载资源,或者显式被标记为可从另一来源加载的资源。
为了从其他来源加载资源,需要支持跨域资源共享(CORS)或跨域资源策略(CORP)。
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: cross-origin
web前端的同学如果使用ajax,如果请求后端地址和页面访问的地址“URL的首部”不同就会出现访问被拒绝的情况,这就需要跨域来解决前后端的通讯问题,下面将列举一些在实际项目中应用也是比较多的方法。
利用js动态创建一个link插入到文档中, 请求css文件,利用 computedStyle = window.getComputedStyle 获取指定元素的 style 对象,利用 computedStyle .content 获取内容
XMLHttpRequest对象(IE中为XMLHTTP对象)是AJAX应用的核心。由于现代浏览器对跨域请求的限制,在使用时需多加注意。本教程尽量用简单易懂的话描述(跨域)问题,并提供一个方案:通过Web代理(Web Proxy)
Jsonp原理是动态创建一个script标签,利用script标签src属性访问没有限制,实现跨域。Ajax是页面无刷新请求数据操作,Jsonp不是真正的ajax请求。讲解Ajax 和 jsonp的区别,在jquery中使用jsonp
JSONP方案:前端提供 API 的方法,其实解耦还没有解的很干净,我们在设置script的src时直接给它传参,后端插入这个参数这就可以了。因为JSONP是通过动态创建Script实现的,动态创建Script只有GET请求没有POST请求
浏览器的同源策略会导致跨域,这里同源策略又分为以下两种:DOM同源策略、XmlHttpRequest同源策略。只要协议、域名、端口有任何一个不同,都被当作是不同的域,之间的请求就是跨域操作。
在开发静态页面时,类似Vue的应用,我们常会调用一些接口,这些接口极可能是跨域,然后浏览器就会报cross-origin问题不给调。最简单的解决方法,就是把浏览器设为忽略安全问题,设置--disable-web-security。
此方案只能用于开发环境,线上最好设置同源策略(遇到个后端,装你妈批),前后端不在同一服务器的情况下,前端要访问后端API,可通过在vue.config.js中配置代理服务器。
在使用vue.js开发前端项目时,再结合webpack搞起各种依赖、各种插件进行开发,无疑给前端开发带来了很多便捷,就在解决跨域这个问题上,相信众多用vue.js的前端同僚们同我一样尝到了甜头
正向代理是你发出请求的时候先经过代理服务器,所以实际上发出请求的是代理服务器。反向代理是“代理你的目标服务器”,请求目标服务器的代理,做一些处理后再真正请求。在这篇文章里,反向代理用于处理跨域问题。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!