Scripting.Filesystemobject filemove，writefile无法在IE浏览器中使用javascript工作（解决方法，doc？）

Question

我知道在浏览器中使用来自javascript的Scripting.Filesystemobject是一个巨大的安全漏洞。我听说MS在最新版本的Office中锁定了这个漏洞。这对我正在开发的企业Web应用程序来说是个坏消息，它有一些关键功能，这些功能依赖于对Scripting.Filesystem对象的访问，比如写出xml文件或移动音频文件。

我已经尝试但未能找到任何'硬'文档，虽然我的本地开发框表现出这种行为，但其他人的机器（除了IE之外没有任何最新版本的机器）没有表现出这种行为。如果有人能指出我确认这一点的文件 - 以及不涉及创建activeX控件的解决方法 - 我将非常感激。

谢谢！

Answer 1

本文kb240797讨论了IE杀戮比特。在注册表中，您将找到此密钥： -

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ ActiveX兼容性

在其下您将找到一组CLSID（FileSystemObject的CLSID为：{0D43FE01-F093-11CF-8940-00A0C9054228}）。如果“Compatibility Flags”值的位（1024位）（kill位），则阻止activex组件。

我也听说MS已经或正在计划杀死FileSystemObject，但我还没有正式看到这一点，而且我目前的系统并不是这样。然而，可能是他们可能会以这种方式阻止它，即使摆弄杀戮位也无济于事。

Answer 2

我不知道这是否有帮助，但我没有听到FileSystemObject被弃用的任何内容。我很想看到你的消息来源。需要注意的另一件事是，作为安全风险而被弃用的最后一个“主要”ActiveX控件是CAPICOM，但这是在Vista发布时宣布的，最后在Windows 7中被删除。文档也被更改以反映这种弃用和提前建议备选方案。

许多（MANY！）shell脚本依赖于FileSystemObject进行文件操作，因此我发现如果不提供替代方法，很难相信它会被弃用。如果它有所不同，仍然可以从IE引擎上运行的Windows桌面小工具访问FileSystemObject。

Answer 3

出于合法或非法的原因，您不应该永远通过浏览器访问用户文件系统。

访问本地存储的非常好的案例是通过Google Gears等系统完成的，甚至这些系统也经常被网络/瘦客户端纯粹主义者所反对。