双击代码全选
|
1
2
3
4
|
dataProtectionProvider.protectAsync(buffer).then(
function (encryptedBuffer) {
SaveBufferToFile(encryptedBuffer);
});
|
encryptedBuffer 参数是 protectAsync 方法的输出且包含缓冲区的加密形式。换句话说，这是可用于存储的加密数据。在此处将 encryptedBuffer 传递给 SaveBufferToFile 方法，该方法将加密数据写入应用程序本地文件夹中的某个文件。
healthItem 的加密概括成以下三行代码：
-
实例化数据保护提供程序。
-
将数据转换为缓冲区。
-
调用 protectAsync 以加密数据。
解密数据也很简单。唯一的变化是使用 DataProtectionProvider 的空构造函数以及使用 unprotectAsync 方法来替代 protectAsync 方法。GetBufferFromFile 方法从在 SaveBufferToFile 方法中创建的文件加载 encryptedBuffer 变量：
双击代码全选
|
1
2
3
4
5
6
7
8
9
|
function btnLoadItem_Click(args) {
var dataProtectionProvider =
Windows.Security.Cryptography.DataProtection.DataProtectionProvider();
var encryptedBuffer = GetBufferFromFile();
dataProtectionProvider.unprotectAsync(encryptedBuffer).then(
function (decryptedBuffer) {
// TODO: Work with decrypted data
});
}
|
开 发人员是否可以将加密用于非 WinRT JavaScript？可以！它是否与提供良好数据保护的三行代码一样简单？不是！浏览器中的加密最佳做法存在很多挑战，如如何保管加密密钥以及管理确保 加密质量所需算法的文件大小。WinRT 数据保护 API 以及 Windows.Security.Cryptography 命名空间中提供的其他加密工具可以轻松保护您的数据。使用 Windows 运行时的安全功能，开发人员可以放心地在 Windows 应用商店应用程序中存储敏感数据，同时使加密密钥易于管理。
本地与Web 上下文
Web 开发人员说： Web 应用程序执行与调用脚本的应用程序同样来源中的外部脚本引用。
Windows 8 开发人员说： Windows 应用商店应用程序将本地应用程序包与外部脚本引用分隔开。
Web 2.0 已培训开发人员，告知他们内容可来自您的网站、其他人的网站（通过糅合）或用户交互。在 Web 上，内容是虚拟的，任何人都可以获取，开发人员使用脚本引用和来自第三方的 API 数据。内容传送网络 (CDN) 和诸如 Bing 地图等在线服务转移了管理代码库或大型数据存储库的开销，使 Web 应用程序可以轻松嵌入功能。降低开销是好事，但是这会带来一些风险。
我们假定保健软件行业中 Contoso 的一个合作伙伴是 Litware Inc，以它为例进行说明。Litware 将发布新的 Exercise API 并为 Contoso Health 开发人员提供了使用
日常操练数据源的密钥。如果 Contoso Health 是 Web 应用程序，开发小组可以使用类似以下的脚本引用实现 Exercise API：
双击代码全选
|
1
|
<script src="https://api.litware.com/devkey/exercise.js"></script>
|
Contoso 的开发人员相信 Litware 将提供正确内容并知道它有好的安全惯例。不幸的是，Litware 的服务器已被一个不满的开发人员侵入，他将 exercise.js 更改为包含一个启动脚本，该脚本显示一条弹出消息：“Contoso Health 需要进行维护；请下载以下维护应用程序”。用户认为此消息是合法的，因而受骗上当下载了恶意软件。Contoso 的开发人员感到困惑：Litware 具有严格的验证，这种安全事件是如何发生的呢？
在 Web 上，以上述方式引用的脚本使用同一站点上脚本的同一来源执行。这意味着 exercise.js（作为 JavaScript 运行）对 DOM 树以及任何脚本对象具有不受审查的访问权限。如前文所述，这可能导致严重的安全问题。为了消除这种风险，Windows 8 将应用程序资源分为两种上下文，如图 2 中所示。
图 2 本地与Web 上下文功能（来自“按上下文划分的功能和限制”[bit.ly/NZUyWt] 和“使用 HTML5 进行安全开发”[bit.ly/JOoMOS]）
本 地上下文可以访问 Windows 运行时以及应用程序包中包含的所有资源（如 HTML、脚本、CSS 和存储在应用程序状态目录中的应用程序数据），但是不能访问远程 HTML、JavaScript 或 CSS（如前文 exercise.js 示例中所述）。Windows 8 中的顶级应用程序始终在本地上下文中运行。在图 2 中，ms-appx:// 用于解析本地上下文中的内容。此方案用于引用在本地上下文中运行的应用程序包中的内容。通常在第三个斜杠 (ms-appx:///) 后面引用包的全名。对于 Web 开发人员，此方法与使用 file:// 协议类似，其中第三个斜杠引用本地文件系统（假定 file://最终用户的计算机/ 替代 file://远程计算机/）。
Web 上下文允许开发人员通过 iframe 将远程内容引入 Windows 应用商店应用程序。与 Web 浏览器中的 iframe 一样，限制在 iframe 中执行的内容访问它外部的资源，如 Windows 运行时和 Windows JavaScript 库的一些功能。（您可以在 bit.ly/PoQVOj 上找到完整列表。） Web 上下文的用途是允许开发人员引用第三方 API（如 Bing 地图）或从 CDN 将库拉入自己的应用程序。
(责任编辑：12图资源库)
