Azure Blob 存储：多个容器的共享访问签名？

Question

我正在创建一个将托管在 Azure 中的应用程序。在此应用程序中，用户将能够上传自己的内容。他们还将能够配置能够读取其文件的其他受信任应用程序用户的列表。我正在尝试弄清楚如何构建存储。

我想我会创建一个以每个用户的应用程序 ID 命名的存储容器，他们将能够在那里上传文件。我的问题涉及如何授予对用户应该有权访问的所有文件的读取访问权限。我一直在阅读有关共享访问签名的信息，它们似乎非常适合我想要实现的目标。但是，我正在评估授予用户访问权限的最有效方式。我认为存储的访问策略可能有用。但具体来说：

我可以使用一个共享访问签名（或存储的访问策略）来授予用户访问多个容器的权限吗？我发现了一条我认为非常相关的信息：

http://msdn.microsoft.com/en-us/library/windowsazure/ee393341.aspx

“一个容器、队列或表最多可以包含 5 个存储的访问策略。每个策略都可以被任意数量的共享访问签名使用。”

但我不确定我是否理解正确。如果一个用户连接了 20 个其他人，我可以授予他或她访问 20 个特定容器的权限吗？当然，我可以生成 20 个单独的存储访问策略，但这似乎效率不高，当他们第一次登录时，我计划显示所有其他受信任的应用程序用户的内容摘要，这相当于要求一次 20 个签名（如果我理解正确的话）。

感谢您的任何建议... -本

Answer 1

由于您将为每个用户拥有一个容器（现在我将一个用户等同于您所谓的用户应用程序 ID），这意味着您将拥有一个存储帐户，该帐户可以为许多用户包含许多不同的容器.如果您想让应用程序能够在读取多个两个选项时仅上传到一个特定容器。

首先：创建一个可以处理所有请求的 API。在 API 之后，您的代码将拥有对整个存储帐户的完全访问权限，因此您的业务逻辑将确定他们可以访问和无权访问的内容。这样做的好处是您根本不必创建共享访问签名 (SAS)。您的应用只知道如何与 API 对话。您甚至可以通过执行并行调用来组合他们可以在该内容摘要中看到的数据，以从应用程序的单个调用中获取来自各种容器的内容。缺点是您现在托管此 API 服务，它必须代理所有这些调用。如果你走这条路，你仍然需要 API 服务来生成 SAS，但只需要生成 SAS 并且客户端应用程序将直接使用 Windows Azure 存储服务进行调用，这将减少资源你真的需要。

第二：走 SAS 路线，根据需要生成 SAS，但这会有点棘手。

您最多只能在每个容器上创建五个存储访问策略。对于这五个之一，您为容器的“所有者”创建一个策略，该策略授予他们读写权限。现在，由于您允许人们向其他人授予读取权限，除非您对读取重复使用相同的策略，否则您将遇到策略计数限制，但是如果用户将某人从他们的帐户中删除，您将无法撤销它“受信任”的读者名单。例如，如果我授予 Bob 和 James 对我的容器的权限，并且他们都获得了 Read SAS 的副本，如果我需要删除 Bob，我必须取消他们共享的 Read Policy 并重新发布一个新的 Read SAS给詹姆斯。不过，这并不是一个真正糟糕的问题，因为该应用程序可以检测到它何时不再具有权限并要求更新 SAS。

无论如何，您仍然希望这些政策是短暂的。如果我从我信任的读者中删除鲍勃，我非常希望他立即被切断。这意味着您将返回获得相当多的更新 SAS 并重新创建签名访问签名，这会降低签名访问策略的有用性。这实际上取决于您计划允许该政策执行多长时间以及如果某人“不受信任”，您希望以多快的速度将其切断。

现在，更好的选择可能是创建 Ad-hoc 签名。您实际上可以拥有任意数量的 Ad-hoc 签名，但它们不能被撤销，并且最多可以持续一小时。既然你会让它们短命，那么长度或没有撤销应该不是问题。走这条路意味着您将让应用程序根据需要返回以获取它们，但考虑到我上面提到的关于某人被移除并且您希望 SAS 用完的情况，这可能没什么大不了的。正如您所指出的，这确实增加了事情的复杂性，因为您正在生成大量 SAS；但是，由于这些是临时的，您实际上并不需要跟踪它们。

如果您打算采用 SAS 路线，我建议您的 API 根据需要生成临时 API。它们的持续时间不应超过几分钟，因为人们可以删除对容器的权限，而您要做的就是减少托管服务的负载以实际进行上传和下载。同样，处理某人可以看到的容器的所有逻辑仍然在您的 API 服务中，并且应用程序只是获得他们可以在短时间内使用的签名。