由于每个用户都将拥有一个容器(现在我将用户等同于您所称的用户应用程序ID),这意味着您将拥有一个存储帐户,其中包含许多不同的容器,供许多用户使用。如果您想使应用程序能够上传到仅一个特定容器而从多个容器中读取,则有两种选择。
第一种:创建一个存在某处的API来处理所有请求。在API后面,您的代码将完全访问整个存储帐户,因此您的业务逻辑将确定他们可以访问和无法访问的内容。其优点是您根本不需要创建共享访问签名(SAS)。您的应用程序只知道如何与API交互。您甚至可以通过对单个应用程序调用并行调用来获取来自各个容器的内容的摘要来合并它们可以查看的数据。其缺点是您现在正在托管此API服务,该服务必须处理所有这些调用。如果您走这条路线,仍然需要API服务生成SAS,但只需要生成SAS,客户端应用程序将直接与Windows Azure存储服务进行通信,分担负载,从而减少实际需要的资源。
第二种:采用SAS路线,并根据需要生成SAS,但这会变得有点棘手。
您只能在每个容器上创建最多五个存储访问策略(Stored Access Policies)。其中之一是为容器的“所有者”创建一个策略,为其提供读写权限。现在,由于您允许其他人给出读取权限,因此除非您重用相同的读取策略,否则您将达到策略计数限制,但然后如果用户将读者列表中的某些人删除,则无法撤消该策略。例如,如果我向Bob和James都授予容器的权限,并且他们都获得了读取SAS的副本,如果我需要删除Bob,我必须取消他们共享的Read策略并向James重新发放新的读取SAS。不过,这不是什么大问题,因为应用程序可以检测到它没有许可证,并请求更新的SAS。
无论如何,您仍然希望策略的寿命很短。如果我从我的可信读者列表中移除了Bob,我几乎希望他立即被切断。这意味着您将经常返回获取更新的SAS并重新创建已签名的访问签名,从而降低了已签名的访问策略的实用性。这实际上取决于您打算允许该策略存活多长时间以及如果有人“不受信任”,您希望多快将其切断。
现在,更好的选择可能是创建特定的签名。
实际上,您可以拥有任意多个特定的签名,但是它们不能被撤销,并且最多只能持续一小时。由于您会使它们的寿命很短,所以长度或缺乏撤销不应成为问题。选择此路线意味着您需要根据需要使应用程序返回获取它们,但考虑到上述情况,当某人被删除且您希望SAS失效时,这可能不是一个大问题。
正如您指出的那样,这确实增加了事情的复杂性,因为您正在生成大量SAS;但是,由于这些是特定的,因此您不需要跟踪它们。
如果您要走SAS路线,我建议您的API根据需要生成特定的SAS。它们不应持续超过几分钟,因为人们可以被删除对容器的权限,而您要做的就是减少托管服务实际执行上传和下载时的负载。同样,处理某人可以看到哪些容器的所有逻辑仍在您的API服务中,而应用程序只获取可以使用一小段时间的签名。