关于跨域的

什么是跨域

要了解跨域,先要说说同源策略。

同源策略是由 Netscape 公司提出的一个著名的安全策略,所有支持 JavaScript 的浏览器都会使用这个策略。

所谓同源是指,域名,协议,端口相同。当页面在执行一个脚本时会检查访问的资源是否同源,如果非同源,那么在请求数据时,浏览器会在控制台中报一个异常,提示拒绝访问。

同源策略一般又分为以下两种:

  • DOM同源策略:禁止对不同源页面DOM进行操作。这里主要场景是iframe跨域的情况,不同域名的iframe是限制互相访问的。

  • XmlHttpRequest同源策略:禁止使用XHR对象向不同源的服务器地址发起HTTP请求。

那么,到底什么是跨域?

跨域,指的是从一个域名去请求另外一个域名的资源。即跨域名请求!跨域时,浏览器不能执行其他域名网站的脚本,是由浏览器的同源策略造成的,是浏览器施加的安全限制。

跨域的严格一点来说就是只要协议,域名,端口有任何一个的不同,就被当作是跨域。

为什么要跨域?

现实工作开发中经常会有跨域的情况,因为公司会有很多项目,也会有很多子域名,各个项目或者网站之间需要相互调用对方的资源,避免不了跨域请求。

跨域解决方案
  • 通过jsonp跨域

  • document.domain + iframe跨域

  • location.hash + iframe

  • window.name + iframe跨域

  • postMessage跨域

  • 跨域资源共享(CORS)

  • nginx代理跨域

  • nodejs中间件代理跨域

  • WebSocket协议跨域


为什么要有跨域限制

了解完跨域之后,想必大家都会有这么一个思考,为什么要有跨域的限制,浏览器这么做是出于何种原因呢。其实仔细想一想就会明白,跨域限制主要是为了安全考虑。


AJAX同源策略主要用来防止CSRF攻击。如果没有AJAX同源策略,相当危险,我们发起的每一次HTTP请求都会带上请求地址对应的cookie,那么可以做如下攻击:

  1. 用户登录了自己的银行页面 mybank.commybank.com向用户的cookie中添加用户标识。
  2. 用户浏览了恶意页面 evil.com。执行了页面中的恶意AJAX请求代码。
  3. evil.commybank.com发起AJAX HTTP请求,请求会默认把mybank.com对应cookie也同时发送过去。
  4. 银行页面从发送的cookie中提取用户标识,验证用户无误,response中返回请求数据。此时数据就泄露了。
  5. 而且由于Ajax在后台执行,用户无法感知这一过程。


DOM同源策略也一样,如果iframe之间可以跨域访问,可以这样攻击:

  1. 做一个假网站,里面用iframe嵌套一个银行网站mybank.com
  2. 把iframe宽高啥的调整到页面全部,这样用户进来除了域名,别的部分和银行的网站没有任何差别。
  3. 这时如果用户输入账号密码,我们的主网站可以跨域访问到mybank.com的dom节点,就可以拿到用户的输入了,那么就完成了一次攻击。

所以说有了跨域跨域限制之后,我们才能更安全的上网了。


跨域的解决方式

> 跨域资源共享

CORS是一个W3C标准,全称是”跨域资源共享”(Cross-origin resource sharing)。 对于这个方式,阮一峰老师总结的文章特别好,希望深入了解的可以看一下ruanyifeng.com/blog/201

这里我就简单的说一说大体流程。

  1. 对于客户端,我们还是正常使用xhr对象发送ajax请求。
    唯一需要注意的是,我们需要设置我们的xhr属性withCredentials为true,不然的话,cookie是带不过去的哦,设置: xhr.withCredentials = true;
  2. 对于服务器端,需要在 response header中设置如下两个字段:
    Access-Control-Allow-Origin: yourhost.com
    Access-Control-Allow-Credentials:true
    这样,我们就可以跨域请求接口了。

> jsonp实现跨域

基本原理就是通过动态创建script标签,然后利用src属性进行跨域。

这么说比较模糊,我们来看个例子:

// 定义一个fun函数
function fun(fata) {
    console.log(data);
};
// 创建一个脚本,并且告诉后端回调函数名叫fun
var body = document.getElementsByTagName('body')[0];
var script = document.gerElement('script');
script.type = 'text/javasctipt';
script.src = 'demo.js?callback=fun';
body.appendChild(script);

返回的js脚本,直接会执行。所以就执行了事先定义好的fun函数了,并且把数据传入了进来。

fun({"name": "name"})

当然,这个只是一个原理演示,实际情况下,我们需要动态创建这个fun函数,并且在数据返回的时候销毁它。

因为在实际使用的时候,我们用的各种ajax库,基本都包含了jsonp的封装,不过我们还是要知道一下原理,不然就不知道为什么jsonp不能发post请求了~

> 服务器代理

浏览器有跨域限制,但是服务器不存在跨域问题,所以可以由服务器请求所要域的资源再返回给客户端。


服务器代理是万能的。

> document.domain来跨子域

对于主域名相同,而子域名不同的情况,可以使用document.domain来跨域 这种方式非常适用于iframe跨域的情况,直接看例子吧 比如a页面地址为 a.yourhost.com b页面为 b.yourhost.com。 这样就可以通过分别给两个页面设置 document.domain = yourhost.com 来实现跨域。 之后,就可以通过 parent 或者 window[‘iframename’]等方式去拿到iframe的window对象了。


使用window.name进行跨域

window.name跨域同样是受到同源策略限制,父框架和子框架的src必须指向统一域名。window.name的优势在于,name的值在不同的页面(或者不同的域名),加载后仍然存在,除非你显示的更改。并且支持的长度达到2M.

//a页面的代码
<script type="text/javascript">
   iframe = document.createElement('iframe');
   iframe.style.display = 'none';
   var state = 0;

   iframe.onload = function() {
     if(state === 1) {
         var data = iframe.contentWindow.name;
         console.log(data);
         iframe.contentWindow.document.write('');
         iframe.contentWindow.close();
         document.body.removeChild(iframe);
     } else if(state === 0) {
         state = 1;
         iframe.contentWindow.location = 
         'http://m.zhuanzhuan.58.com:8887/b.html';
     }
   };
   document.body.appendChild(iframe);
</script>


//b页面代码
<script type="text/javascript">
   window.name = "hello";
</script>


> location.hash跨域

location.hash方式跨域,是子框架具有修改父框架src的hash值,通过这个属性进行传递数据,且更改hash值,页面不会刷新。但是传递的数据的字节数是有限的。

//a页面的代码
<script type="text/javascript">
   iframe = document.createElement('iframe');
   iframe.style.display = 'none';
   var state = 0;

   iframe.onload = function() {
     if(state === 1) {
         var data = window.location.hash;
         console.log(data);
         iframe.contentWindow.document.write('');
         iframe.contentWindow.close();
         document.body.removeChild(iframe);
     } else if(state === 0) {
         state = 1;
         iframe.contentWindow.location = 
         'http://m.zhuanzhuan.58.com:8887/b.html';
     }
   };
   document.body.appendChild(iframe);
</script>


//b页面代码
<script type="text/javascript">
   parent.location.hash = "world";
</script>


> 使用postMessage实现页面之间通信

信息传递除了客户端与服务器之前的传递,还存在以下几个问题:

  • 页面和新开的窗口的数据交互。
  • 多窗口之间的数据交互。
  • 页面与所嵌套的iframe之间的信息传递。

window.postMessage是一个HTML5的api,允许两个窗口之间进行跨域发送消息。这个应该就是以后解决dom跨域通用方法了,具体可以参照MDN。

补充: 其实还有一些方法,比如window.name和location.hash。就很适用于iframe的跨域,不过iframe用的比较少了,所以这些方法也就有点过时了。

这些就是我对跨域的了解了,实际情况下,一般用cors,jsonp等常见方法就可以了。不过遇到了一些非常规情况,我们还是需要知道有更多的方法可以选择的

转载自https://zhuanlan.zhihu.com/p/28562290

<think>嗯,用户想了解身份认证的方法,结合之前的对话历史和系统指令,需要系统整理相关信息。用户引用了多个资料片段,重点提到了Session-Cookie的局限性和JWT的优势,特别是场景下的适用性。从技术角度看,认证的核心痛点是浏览器同源策略对Cookie限制。Session-Cookie方案在时需要额外配置CORS和withCredentials属性,安全性也容易受CSRF攻击影响。而JWT的无状态特性天然适合,Token可以放在请求头里自由传递,但要注意Token存储安全性和过期机制。用户可能是前端开发者或全栈工程师,正在设计系统认证方案。ta提到的单点登录需求值得重点关注,需要解释JWT如何配合OAuth2实现多系统间的信任传递。引用[3]中提到的统一身份认证场景很典型,应该用SSO方案展开说明。回复结构上先分Session和JWT两类方法,再补充单点登录场景。重点对比两者的实现差异,比如JWT如何解决Cookie问题,以及服务端如何验证Token签名。引用资料时要把参考标记自然地融入说明文字里,比如提到Express框架的使用就可以关联引用[1][4]。用户可能还有隐含需求,比如想了解具体代码实现或性能考量。可以准备回答Session共享方案(Redis集群)、CORS配置细节、JWT加解密开销等问题。</think> 身份认证的常用方法及适用场景如下: --- ### 一、Session-Cookie 方案(需配置) 1. **基本原理** - 服务端存储用户Session,通过Set-Cookie返回Session ID给前端 - 浏览器后续请求**自动携带Cookie**(需开启`withCredentials`) 2. **问题解决** ```java // Spring Boot示例(引用[2]) @CrossOrigin(origins = "https://client-domain.com", allowCredentials = "true") ``` - **必要条件**: - 前端:`axios.defaults.withCredentials = true` - 后端:`Access-Control-Allow-Credentials: true` - 域名白名单:`Access-Control-Allow-Origin: https://client-domain.com` 3. **缺点**: - 需服务端维护Session存储 - 配置复杂(引用[1][4]) - CSRF攻击风险 --- ### 二、JWT(JSON Web Token)方案(推荐使用) 1. **核心机制**(引用[1][4]): ```mermaid graph LR A[用户登录] --> B[服务端生成JWT] B --> C[返回Token给前端] C --> D[前端存储Token] D --> E[请求时携带Authorization头] ``` 2. **优势**: - 无状态:服务端不存储会话 - 天然支持:通过HTTP Header传递 - 典型Token格式:`Bearer eyJhbGci...` 3. **Express实现示例**(引用[1]): ```javascript // 生成Token const token = jwt.sign({userId: 123}, 'secretKey', {expiresIn: '2h'}); // 验证中间件 const auth = (req, res, next) => { const token = req.header('Authorization')?.replace('Bearer ', ''); jwt.verify(token, 'secretKey', (err, decoded) => { if(err) return res.status(401).send(); req.user = decoded; next(); }); } ``` --- ### 三、单点登录(SSO)方案(引用[3]) 1. **系统认证流程**: ``` 用户访问A系统 → 重定向至认证中心 → 登录后携带Token返回A系统 → 访问B系统时认证中心自动授权 ``` 2. **关键技术**: - 中央认证服务器 - Token共享(如JWT) - Cookie + OAuth2.0协议 --- ### 四、方案对比表 | **方案** | 复杂度 | 安全性 | 适用场景 | |----------------|------------|------------|------------------------| | Session-Cookie | 高⭐ | 易受CSRF | 同主下的子系统 | | JWT | 低✅ | 需防XSS | API/微服务架构 | | SSO | 中⚠️ | 最高🔒 | 企业级多系统统一认证 | --- **总结建议**: 1. 纯前端调用API → **优先JWT方案**(引用[4]) 2. 企业内部系统整合 → **SSO + JWT组合** 3. 传统Web应用(同) → Session方案更简单 > 附:前端存储Token的安全方式 > ```javascript > // 避免LocalStorage(防XSS),使用HttpOnly Cookie > document.cookie = `token=${token}; Secure; SameSite=None; HttpOnly`; > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值