Azure blob 存储 : Shared access signature for multiple containers?

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 对我的容器的权限，并且他们都获得了读取 SAS 的副本，如果我需要删除 Bob，我将不得不取消他们共享的读取策略并重新发布新的读取 SAS给詹姆斯。不过，这并不是一个严重的问题，因为该应用程序可以检测到它何时不再具有权限并要求更新 SAS。

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

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

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