mip-script 标签实现方案 about mip2 HOT 6 CLOSED

待补充 AST 分析方案 @ccksfh

from mip2.

方案大体同上，但是我的想法是，如果发现全局变量不在白名单中，不中止执行 js，删除这个 expression
沙盒机制与 #5 保持一致

另外 ast 方案目前使用的是 esprima + estraverse + escodegen，打出来的包大概是目前 mip.js 的一半了。。试过 babylon + babel-traverse + babel-generator 的方案，更大，接近目前方案的两倍

有个问题是，mip-script 组件会被包在 sandbox 里，这导致我分析完之后的 script 找不到方法来执行，这个比较头疼 mip-cli 会做组件白名单，对部分组件不注入沙盒，这个问题结了

from mip2.

发现全局变量不在白名单中，应该中止执行 JS 吧？如果只是删除这个 expression 不会会导致部分代码没执行，程序不完整，会报错吗？

from mip2.

目前 mip-script 的沙盒机制跟组件保持一致

现在 @clark-t 的策略是，在白名单内不做替换，直接使用全局变量（因为是安全的，直接使用正常 window 下的变量，如 console）；不在白名单内（不安全的）就替换成 MIP.sandbox 的（经过重新定义的 - 如 window/window.xxx，或没有经过定义的）。当然问题在，不在白名单内的变量替换后，如果MIP.sandbox 下没有实现，同样可能不能正常使用。某种程度上跟中止执行效果类似吧，不过中止的操作就相对更简单了。在目前的策略下，我可以在替换的同时给开发者提示，是否触发了红线

跟一开始说的 “白名单内就替换，保证使用的是沙盒里面的变量” 有些不一致

from mip2.

mip-script 的白名单应该比组件的白名单更加严格

因为组件会经过我们的人工审核，但是 HTML 并不会，所以，要以最严格的方式限制开发者编写 JS，至少从一开始要从紧到松

所以，在你们把方案完成之后，我们回过头再来仔细 review 这个开放给开发者的白名单。

from mip2.

关于 mip-script 校验，我认为意义不大，不如不做。

如上次讨论，沙盒对全局变量属性和方法检查困难，即无法检查如 window.alert()，仅检查如 window、BAIDU 此类全局变量，所以方案整体通过沙盒变量替换机制来保证 “安全”，在这个方案下沙盒仅能输出全局变量的检测，即出现了认为 window.alert() 是安全的，而 BAIDU 是不安全的。这种标准的不一致使校验实际上既没有起到 准入的作用，也没有起到 提示开发者规范 的作用。

另外，页面检验有前后端两部分，后端校验用于 MIP 页面准入，前端用于开发者开发过程中检查自己是否符合准入规范。基于这一设计原则，前后端校验规则需要保持一致，我对 MIP 页面校验 “前端校验可以更严格” 暂时不赞同。

建议方案：

1. 关于准入，沙盒提供完整的检测机制，校验才能提供完善的准入。
2. 关于开发者提示，依靠文档和页面/组件调试、运行时提供全局变量及其方法使用提示。

from mip2.