由于您将为每个用户拥有一个容器（现在我将一个用户等同于您所谓的用户应用程序 ID），这意味着您将拥有一个存储帐户，该帐户可以为许多用户包含许多不同的容器。如果您想让应用程序能够仅上传到一个特定的容器，同时从许多两个选项中读取数据。
第一：创建一个 API 来处理所有请求。在 API 之后，您的代码将拥有对整个存储帐户的完全访问权限，因此您的业务逻辑将确定他们可以访问和无法访问的内容。这样做的好处是您根本不必创建共享访问签名 (SAS)。您的应用只知道如何与 API 对话。您甚至可以通过执行并行调用来组合他们可以在该内容摘要中看到的数据，以从应用程序的单个调用中获取来自各种容器的内容。缺点是您现在托管此 API 服务，它必须代理所有这些调用。如果你走那条路，你仍然需要 API 服务来生成 SAS，
第二：走 SAS 路线，根据需要生成 SAS，但这会有点棘手。
您最多只能在每个容器上创建五个存储访问策略。对于这五个中的一个，您为容器的“所有者”创建一个策略，该策略授予他们读取和写入权限。现在，由于您允许人们向其他人授予读取权限，除非您对读取重复使用相同的策略，否则您将遇到策略计数限制，但是如果用户将某人从他们的帐户中删除，您将无法撤销它“受信任”的读者名单。例如，如果我向 Bob 和 James 授予对我的容器的权限，并且他们都获得了 Read SAS 的副本，如果我需要删除 Bob，我将不得不取消他们共享的 Read Policy 并重新发布一个新的 Read SAS给詹姆斯。不过，这并不是一个真正糟糕的问题，因为该应用程序可以检测到它何时不再具有权限并要求更新 SAS。
无论如何，您仍然希望这些政策是短暂的。如果我从我信任的读者中删除鲍勃，我非常希望他立即被切断。这意味着您将返回获取更新的 SAS 并重新创建签名访问签名，这会降低签名访问策略的有用性。这实际上取决于您计划允许该政策生存多长时间以及如果某人“不受信任”，您希望他们多快被切断。
现在，更好的选择可能是您创建 Ad-hoc 签名。您实际上可以拥有任意数量的 Ad-hoc 签名，但它们不能被撤销，并且最多可以持续一小时。既然你会让它们短命，那么长度或没有撤销应该不是问题。走这条路意味着您将让应用程序根据需要返回以获取它们，但考虑到我上面提到的关于某人被移除并且您希望 SAS 用完的情况，这可能没什么大不了的。正如您所指出的，这确实增加了事情的复杂性，因为您正在生成大量的 SAS；但是，由于这些是临时的，您实际上并不需要跟踪它们。
如果您打算走 SAS 路线，我建议您的 API 根据需要生成临时的。它们的持续时间不应超过几分钟，因为人们可以删除对容器的权限，而您要做的只是减少托管服务的负载以进行实际上传和下载。同样，处理某人可以看到的容器的所有逻辑仍然在您的 API 服务中，应用程序只是获得他们可以在短时间内使用的签名。