我正在创建一个将在Azure中托管的应用程序。在此应用程序中，用户将能够上传自己的内容。他们还将能够配置能够读取其文件的其他受信任应用用户的列表。我正在试图弄清楚如何构建存储。
我认为我将创建一个以每个用户的应用程序ID命名的存储容器，并且可以在那里上传文件。我的问题涉及如何授予用户应该访问的所有文件的读访问权限。我一直在阅读有关共享访问签名的内容，他们似乎非常适合我正在努力实现的目标。但是，我正在评估授予用户访问权限的最有效方式。我认为存储访问策略可能很有用。但具体来说：
我可以使用一个共享访问签名（或存储的访问策略）来授予用户访问多个容器的权限吗？我发现了一条我认为非常相关的信息：
http://msdn.microsoft.com/en-us/library/windowsazure/ee393341.aspx
“容器，队列或表最多可包含5个存储的访问策略。每个策略都可以由任意数量的共享访问签名使用。”
但我不确定我是否理解正确。如果用户与其他20个人连接，我可以授予他或她访问20个特定容器的权限吗？当然，我可以生成20个单独的存储访问策略，但这看起来效率不高，当他们第一次登录时，我计划显示来自所有其他可信应用用户的内容摘要，这相当于要求一次签署20个签名（如果我理解正确的话）。
感谢您的任何建议...... -ben
答案 0 :(得分：9)
由于您将为每个用户创建一个容器（现在我将用户与您所谓的用户应用程序ID等同），这意味着您将拥有一个可以为许多用户包含许多不同容器的存储帐户。如果您希望应用程序能够上传到一个特定的容器，同时从脑海中读取两个选项。
首先：创建一个存在于处理所有请求的API的API。在API后面，您的代码将拥有对整个存储帐户的完全访问权限，因此您的业务逻辑将确定他们执行和无权访问的内容。这样做的好处是您根本不必创建共享访问签名（SAS）。您的应用只知道如何与API通信。您甚至可以通过并行调用来组合他们可以在内容摘要中看到的数据，以便从应用程序的单个调用中获取来自各种容器的内容。缺点是您现在正在托管此API服务，该服务必须代理所有这些调用。如果你走这条路线，你仍然需要API服务来生成SAS，但只需要生成SAS，而客户端应用程序将直接使用带有负载的Windows Azure存储服务进行调用，这将减少资源你真的需要。
第二：走SAS路线并根据需要生成SAS，但这会有点棘手。
每个容器最多只能创建五个存储访问策略。对于这五个中的一个，您为容器的“所有者”创建一个策略，该策略为其提供读写权限。现在，由于您允许人们向其他人提供读取权限，您将遇到策略计数限制，除非您为Read重用相同的策略，但如果用户从他们中删除某人，您将无法撤销该权限“值得信赖”的读者名单。例如，如果我将Bob和James的权限授予我的容器并且他们都交给了Read SAS的副本，如果我需要删除Bob，我必须取消他们共享的Read Policy并重新发布一个新的Read SAS对詹姆斯虽然应用程序可以检测到它何时不再拥有权限并要求更新SAS，但问题并不是那么糟糕。
在任何情况下，你仍然希望政策是短暂的。如果我从可靠的读者那里删除了鲍勃，我非常希望他能立即切断。这意味着您将重新获得更新的SAS并重新创建签名访问签名，这会降低签名访问策略的实用性。这实际上取决于你的胃，你计划允许政策生存的时间长短，以及如果他们“不信任”你想要有人切断的速度。
现在，更好的选择可能是您创建Ad-hoc签名。您可以根据需要拥有尽可能多的Ad-hoc签名，但它们不能被撤销，最多可以持续一小时。既然你让它们短暂，那么长度或缺乏撤销不应成为问题。走这条路线意味着你会让应用程序回来根据需要得到它们，但考虑到我上面提到的关于何时被移除并且你希望SAS耗尽这可能不是什么大问题。正如你所指出的那样，这确实增加了事物的复杂性，因为你生成了很多SAS;然而，由于这些是临时的，你并不需要追踪它们。
如果你打算走SAS路线，我建议你的API根据需要生成ad-hoc。它们不应该持续超过几分钟，因为人们可以将其权限移除到容器中，而您尝试做的只是减少托管服务的负载以实际上传和下载。同样，处理某人可以看到的容器的所有逻辑仍然在您的API服务中，并且应用程序只获得可以在很短的时间内使用的签名。