作者:卢峰(清锐)
本文简要介绍了 Script Error 问题的来龙去脉,但也不局限于 Script Error,对于通用的系统性问题,应该找到系统性解决方案,进而治标治本。
Script Error 原因与当前解法
受浏览器同源策略限制,未知跨域脚本执行错误时,抛出的错误信息为 “Script error.”,导致开发者无法定位具体错误。为了获取详细错误信息及堆栈,一般解法是给 Script 标签配置 crossorigin 属性,同时对应脚本服务端需配置 Access-Control-Allow-Origin 响应头。
另外还有一些 hack 解法,对浏览器原生 API 做代理,将业务代码放在 Try Catch 作用域中执行,但写好代理方法是不容易的,粗制滥造的代理方法会制造很多隐藏 Bug,并且大量 Try Catch 在一些 JS Engine 中也存在额外性能损耗,为了解决 Script Error 采用此方案得不偿失。
还有什么问题
- crossorigin 不好加
异步加载脚本套娃,A 加载 B,B 加载 C,以至于不知道加载了哪些外部脚本
需要服务端配合设置响应头 Access-Control-Allow-Origin
- crossorigin 加不了
外部注入代码,如浏览器插件、定制 Webview 容器(xx 浏览器)
- 无效 Script Error 数据,难以评估对业务实际影响,并且耗费监控资源
溯源:为什么是 Script Error
从 2006 年一篇安全漏洞文章说起:I know if you’re logged-in, anywhere
在那个年代大量网站都是服务端渲染,服务端根据用户登录态返回不同页面内容,黑客通过 Script 加载目标