Iframe 内嵌复盘

公司系统较多,业务之间交集,做引流,不想重复开发,往往就需要内嵌:

一、嵌入方

1. 嵌入方式
//待修改  加每个参数的实际含义
<template>
  <div class="iframe-container">
      <iframe id="iframe" ref="iframeRef" :src="checkSrc()" width="100%" height="100%" allowfullscreen sandbox="allow-scripts allow-forms allow-modals allow-pointer-lock allow-popups allow-popups-to-escape-sandbox allow-same-origin allow-storage-access-by-user-activation allow-top-navigation-by-user-activation allow-downloads"></iframe>
  </div>
</template>

Tips:

  • 本身HTTP, 内嵌方 HTTPS,或者是HTTP 都支持

  • 本身HTTPS,内嵌方是HTTP,浏览器会认为不安全,有时候HTTPS资源也可能被检测判为不安全,因此,如果自身系统,经常需要内嵌诸多外部系统,暂时以HTTP 方式运行可获取最大的兼容性

  • 为保证客户打开网页一直走HTTP,可以让运维帮忙配置重定向,把HTTPS重定向到HTTP

  • 内嵌会使得被嵌入方,普通cookie的设置和读取受到影响,如果被嵌入方 把登录token以cookie的方式存储,那么会导致网页登录失败

    (1) 同源策略
    同源策略是浏览器的一项基本安全策略,它规定了来自不同源(即协议、域名、端口三者完全一致)的内容间不能相互访问资源。当iframe加载的是与主页面不同源的网页时,由于同源策略的限制,iframe内部网页通常无法访问主页面的cookie,反之亦然。

    (2) 第三方Cookie限制
    如果iframe加载的是第三方站点,浏览器可能会阻止iframe从顶级上下文中读取或写入
    cookie,特别是当涉及到用户隐私和安全时,这种限制更为严格。

    (3) SameSite Cookie属性
    SameSite 是cookie的一个属性,用于指定cookie是否应该伴随跨站请求发送。默认情况
    下,或当设置为 SameSite=Lax 时,浏览器将不允许在一个跨站上下文中(如iframe内)
    发送非安全(non-secure)的SameSite cookie。被内嵌方如需存取cookie,设cookie时就要设这个属性

    (4) Secure Cookie属性
    若cookie设置了 Secure 属性,则cookie只能通过HTTPS协议传输,这意味着在非加密
    HTTP连接中,iframe无法获取带有 Secure 属性的cookie。被内嵌方如需存取cookie,设cookie时就要设这个属性

    (5) P3P政策
    对于旧版Internet Explorer浏览器(已不再主流支持),iframe内的网页可能需要遵循
    P3P(Platform for Privacy Preferences)隐私策略声明才能读取或写入cookie。如果没
    有正确的P3P头信息,IE浏览器可能会阻止iframe中的cookie交互。

    (6) httpOnly
    该属性必须由客户端或者是中间层服务中设置,端上无法设置,将Cookie设置为HttpOnly是为了增加cookie的安全性,防止恶意脚本获取Cookie,从而防止XSS攻击和某些CSRF攻击。HttpOnly的cookie仅能通过HTTP(和HTTPS)协议访问,而不能通过JavaScript等脚本访问。这样即使有XSS攻击成功注入了恶意脚本,也无法读取到cookie的值,提高了cookie的安全性。值得注意的是如果在我们在内嵌网页的服务端或中间层服务对cookie中设置了httpOnly,那么第一次设置cookie会成功,但是第二次,在外部是http 的协议前提下,是无法修改的,而如果内嵌方需要设置cookie,我们现在都是设置 Secure和 SameSite两个属性,这样比如我们的iframe链接需要不断更新时,就能更新成功。 但值得注意的是如果在无痕的环境下,cookie 依然无法被覆盖。 因此一般我们采用内嵌方案时,对方需要登录并且是依赖cookie完成的整套登录校验,那就需要格外注意了。

2. 接收消息
function handleMessage(event) {
  let data = event.data;
  console.log(data)
}
// 也要做好每次进来的清除
onMounted(() => {
    window.removeEventListener('message', handleMessage);
    window.addEventListener("message", handleMessage, false);
  });
// 或者在离开的时候
onUnmounted(() => {
    window.removeEventListener('message', handleMessage);
  });
3. 测试被嵌入方发来信号
 // !!测试支付提示弹窗
   setTimeout(() => {
      window.parent.postMessage(
        {
          type: 'clickPay',
          data: {
            title: '订单提交通知',
            roomGuest: 'XX',
            phone: 'XX',
            desc: 'XX'
          },
        },
        '*'
      );
    }, 5000);
// 对接方
const handleMessage = (e) => {
    const res = e?.data || {};
    if (res.type === 'clickPay') {
      console.log(res.data);
    }
  };
4. 帮助被内嵌系统免登陆实现
  • 首先第一步就是要拿到token
    1、同一个公司的登录往往是走公共,是统一的,此时token 可互通,把token传下去即可
    2、如果不相通,也可让被嵌入方提供接口,我们去调接口,传入工号和姓名,或卡号等信息,注册,并得到token,然后也是参数的方式往下传递

  • 约定好参数传入

// 直接把对token 通过参数形式传给被嵌入方
<iframe data-v-278c76dc="" width="100%" height="441px" src="https://m.ly.com/hotel?AUTH_TOKEN=XXXXX&if=5006942" frameborder="0" sandbox="allow-same-origin allow-scripts"></iframe>

Tips:

  • 1、iframe 内嵌可以在调试窗口,修改element中的链接直接触发重新加载
  • 2、记得可以拿被嵌入方的链接 提前测试一下,可以关注下比如内嵌之后是否有部分资源,接口,图片加载异常,如果自身是https 域名的,那么这类情况大概率会出现
  • 3、如果被内嵌方是cookie 处理登录流程的, 自身是http协议, 此时为了让被嵌入方可以完成登录,设置了secure 和same site 这些属性,并且为了更新没有设置httpOnly, 需要提醒用户不可用无痕浏览器,否则cookie 这套依然会行不通
  • 4、不走参数,想要把token 传给被嵌入方,我们还有一种方式,那就是利用sdk,一般需要被嵌入方提供,我们调用, 这样也是一种把token传下去,且不暴露在外面的,更安全的方式
  • 5、值得一提的是如果我们自身是https,而被嵌入方也是https, 公司所有站都实现了https 协议,未来也不用考率http 的可能,那么对于cookie更新这块,我们建议 httpOnly 属性也加上会更好!!
  • 6、
  • 7、在很多时候,我们需要不断尝试,才知道一些方案是否真的有效,不要意气用事,先入为主,道听途说, 内嵌接入前一定做好充分的尝试和调研

二、被嵌入方

  • 1、约定好实际的参数情况,走window.postMessage,如上照做即可。
  • 2、如果页面中存在各种情况。比如有些window.parent window.top window.self 等,操作, 一定要注意兼容问题,因为在iframe 环境中,会被认为想要操作, 可以参照 内嵌操作window兼容 来处理兼容性问题
  • 3、最好是拿到token 解析,解决登录,有时候系统是需要走统一登录回跳,利用cookie 埋登录信息的情况,那么参考上面,对cookie的处理吧
希望能帮助到大家少走一些弯路,给我多多鼓励,我会继续出一些实用的编码经验和技巧分享给大家,需要前端技术资料可以关注下 Famous 看世界 ~
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 201,312评论 5 473
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,578评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 148,337评论 0 333
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,134评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,161评论 5 363
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,303评论 1 280
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,761评论 3 393
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,421评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,609评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,450评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,504评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,194评论 3 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,760评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,836评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,066评论 1 257
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,612评论 2 348
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,178评论 2 341

推荐阅读更多精彩内容