以下方案旨在帮助说明 Flash Player 8 中的新本地安全规则的效果。
用户方案: Flash 作者和同事
设计 Flash Player 8 本地安全规则的目的是为了帮助保护最终用户。对于最终用户而言, 本地 SWF 通常是最终内容, 即从 Internet 下载的内容或作为应用程序的一部分安装的内容。但对于 Flash 作者而言, 本地 SWF 通常只是开发中内容的临时副本, 即通常是要绑定以在 HTTP 服务器上进行最终部署的内容。有时, 您可能会遇到阻止内容正常运行的安全限制, 这只是因为您正预览的 SWF 仍然是本地文件。
请考虑使用以下三种方法来测试开发中的 Flash 内容, 这三种方法按复杂性依次递增的顺序排列:
-
在 Flash 创作应用程序中测试影片。测试影片播放器根本不强制实施新的本地安全规则, 因此在测试影片模式中应该不会出现任何问题。
-
使用独立播放器或浏览器播放器查看本地 SWF。这可能会产生因新规则而导致的问题, 例如, 当 SWF 使用 HTTP URL 调用 getURL 时。
-
将 SWF 放在 HTTP 测试服务器上, 并使用浏览器进行查看。这种形式的测试同样不会引发本地安全问题, 这是因为通过 HTTP 查看的 SWF 不是本地 SWF；它们运行于 Flash Player 远程安全规则之下, 而这些规则在 Flash Player 8 中并未更改。
如果 Flash Player 能够区分开发中的 Flash 内容与从 Internet 下载的不受信任的 SWF, 则上述方法将非常理想和有用, 它可以在使用浏览器进行预览的测试中避免出现不需要的安全限制。遗憾的是, 没有可靠的自动方式来使 Flash Player 实现此测试。
相反, 您可能会发现, 将 Flash Player 配置为信任本地文件系统中某一区域内的所有 SWF 将非常有用。例如, 如果将所有 Flash 工作都存储在 C:\FlashSites 下, 则可以访问 设置管理器并将目录 C:\FlashSites 添加到受信任路径的列表中。此后, 只要查看 C:\FlashSites 或其任意子目录中的任何 SWF, Flash Player 就会将这些 SWF 放在受信任的本地沙箱中, 以免出现任何与安全相关的故障。如果执行了此操作, 那么一定不要将不受信任源中的 SWF 放到信任区域中！将您自己的本地 SWF 与其它作者的不受信任的 SWF 分离, 这样便可加强对您的保护, 如同对所有 Flash Player 最终用户的保护一样。
假设您已访问设置管理器并已配置了受信任的目录。那么, 您现在即可以开展自己的工作, 而不受安全问题的困扰。但是, 您可能需要将开发中的 SWF 与众多同事 (HTML 作者、Flex 开发人员、位图艺术家等) 共享。或者, 您可能希望向经理或客户演示您的 SWF。而他们中的一些人可能并未在其计算机中设置受信任的目录, 因此如果这些人以本地文件的方式打开您的 SWF, 并且 SWF 尝试与 Internet (例如, 通过调用 getURL) 或 HTML 页通信, 则在对您的内容进行本地预览时, 本地安全规则可能会导致这些内容无法正常运行。此外, 由于这些“延伸”用户可能没有在其计算机中安装 FlashAuthor.cfg, 因此如果您的 SWF 是版本 8 或更高版本, 那么这些人甚至无法看到提示故障原因的警告对话框。
遗憾的是, 尚没有一种方法可以处理这些延伸用户问题。基本问题是, 如果 Flash Player 在您同事的计算机上运行, 则它无法区分 (临时) 本地 SWF 和从 Internet 下载的可能不受信任的 SWF。
解决此延伸用户问题最可靠的方法是将 SWF 张贴到 HTTP 测试服务器上, 然后发送链接, 而不是将 SWF 作为文件来发送。但有时这样做可能不方便于或无法使用这种方法, 例如, 如果您没有专用 HTTP 服务器, 或者您需要将 SWF 与您网络以外的人共享, 而且您不想将 SWF 张贴到公共服务器上。因此, 您可能需要考虑使用其它方法:
- 创建 SWF 放映文件
- 将 SWF 发布为供网络使用而非供本地文件系统使用
- 为 SWF 项目创建可设置 FlashPlayerTrust 文件的安装程序
- 向同事发送设置管理器配置说明
- 请求同事将 SWF 张贴到他们自己的服务器上
适用于您的最佳解决方案取决于您的具体情况。
用户方案: Flash Player 最终用户
在大多数情况下, Flash Player 最终用户应该看不到新的本地安全规则。但如上所述, 某些用户可能具有为了与 Internet 通信而编写的本地 Flash 应用程序。当这些用户升级到 Flash Player 8 时, 他们可能会看到一个对话框, 告知他们存在潜在不安全的操作。
在此情况下, 用户的选择非常简单。他们可以决定忽略该问题, 可以与应用程序供应商联系以咨询解决方法, 也可以选择自行尝试并解决该问题。
决定解决该问题的用户可以单击警告对话框中的“设置”按钮。此时用户将进入设置管理器, 他们可以在此阅读有关本地安全的信息, 选择“编辑位置” › “添加位置”, 然后选择要信任的本地路径。指出需要信任的路径并非总是很繁琐；有时只信任警告对话框中出现的单个路径便足已, 但有时一个应用程序中可能涉及多个 SWF。在这种情况下, 可能需要信任包含这些 SWF 的整个目录。每次猜测受信任的路径后, 用户必须返回到初始应用程序并重新启动该应用程序, 例如, 通过刷新浏览器来执行此操作。
进入设置管理器后, 用户还可以选择“始终允许”信任版本 7 及更早版本的所有 SWF。与确定信任路径相比, 这种解决方法更为简单, 但它在提供这种便利的同时, 降低了用户的安全性。
应用程序方案: 修复混合帮助系统
假设您正在维护使用本地 SWF 的应用程序, 并且有用户反映在查看应用程序的某些部分时看到提示可能存在不安全操作的 Flash Player 安全对话框。假定您的应用程序是一个混合帮助系统, 该系统是本地 SWF 应用程序的一种常见形式: 使用 getURL 或 fscommand 通信的 HTML 和 SWF 文件的集合。
第一步应该是确定问题的严重性。是一个重要应用程序的关键组件出现了重大问题？还是业余项目中的一个小功能被破坏了？是否要向所有用户重新分发修复后的文件？答案通常是肯定的, 但在进行修复之前务必确认修复需求。
一种方法是只告知用户访问设置管理器并信任帮助系统所在的路径。但某些用户可能会因步骤过多而无法完成, 并且如果用户不理解安全决策的含义, 则有可能给他们带来不便。
另一种方法是将 SWF 重新发布为供网络使用, 或使用 Local Content Updater 对这些 SWF 进行后处理。如果您的内容所产生的唯一安全冲突来自对 getURL 的调用, 则这种方法应足以解决问题。但是, 如果您的 SWF 和 HTML 文件使用 fscommand、getURL("javascript:...") 或其它混合脚本处理操作, 则供网络使用的本地沙箱不足以将应用程序恢复到以前的状态；必须将 SWF 放在受信任的本地沙箱中。
如果用户的技术知识丰富, 则可以为他们提供 FlashPlayerTrust 文件以及放置该文件的说明。或者, 也可以创建可在适当位置自动创建 FlashPlayerTrust 文件的小脚本或程序。如果您知道 SWF 的安装位置, 则只需信任您希望它们所在的目录。但是, 如果用户选择了非默认安装位置, 则可能需要提示用户提供您的内容的安装位置, 或在他们的文件系统中搜索您的 SWF。
应用程序方案: 偶尔连接的联系人管理器
这是最后一个方案, 我们假设您正在构建本地 SWF 应用程序, 该应用程序可定期与 HTTP 服务器同步数据, 而在其它时间则用作该数据的本地存储库。讨论的数据可能是一个地址簿, 因此将此应用程序视为“偶尔连接的联系人管理器”。
假定您已经确定需要网络发送权限, 而不是本地读取权限, 例如, 您不需要读取本地 XML 文件以进行配置。因此, 在发布 SWF 时, 需在 Flash 发布选项中的“本地回放安全性”下选择“只访问网络”。现在, 您的 SWF 可以随意使用 getURL、XML.load 和其它 HTTP 操作。
现在, 您可以将应用程序连接到 HTTP 数据源, 以进行同步。假定您使用 XML.sendAndLoad() 来交换简单的 XML 数据。由于 XML.sendAndLoad 是一个网络读取操作, 因此您需要在正与之同步的 HTTP 服务器上有一个策略文件。假设您希望该策略文件只控制相关数据, 而不是整个 HTTP 服务器, 因此您将该文件放在 XML 数据源旁, 并在客户端 SWF 中调用 System.security.loadPolicyFile, 以指定该策略文件的位置。策略文件如下所示:
