Azure blob容器共享访问签名即将过期

我在Azure Blob和共享访问签名过期时遇到问题。我需要在超过1小时（7天）的时间内授予对blob的访问权，因此我使用了命名容器策略，但不幸的是，在这7天结束后，我似乎无法生成新的URL

我有以下代码来创建“默认”策略。注意：在这段代码中，我将过期时间设置为1分钟，以便于测试：

CloudStorageAccount account = new CloudStorageAccount(credentials, true);

CloudBlobClient client = new CloudBlobClient(account.BlobEndpoint, credentials);

CloudBlobContainer container = client.GetContainerReference("files");

SharedAccessPolicy sharedAccessPolicy = new SharedAccessPolicy();
sharedAccessPolicy.Permissions = SharedAccessPermissions.Read;
sharedAccessPolicy.SharedAccessStartTime = DateTime.UtcNow;
sharedAccessPolicy.SharedAccessExpiryTime = DateTime.UtcNow.AddMinutes(1);

BlobContainerPermissions blobContainerPermissions = new BlobContainerPermissions();
blobContainerPermissions.SharedAccessPolicies.Add("default", sharedAccessPolicy);

container.SetPermissions(blobContainerPermissions);

然后，我使用以下内容创建SharedAccessSignature url：

CloudStorageAccount account = new CloudStorageAccount(credentials, true);

CloudBlobClient client = new CloudBlobClient(account.BlobEndpoint, credentials);

CloudBlobContainer container = client.GetContainerReference("files");

CloudBlob blob = container.GetBlobReference(path);

string sas = blob.GetSharedAccessSignature(new SharedAccessPolicy(), "default");

Console.WriteLine(blob.Uri.AbsoluteUri + sas);

这将生成一个url，并且该url在下一分钟（或者在实际代码中为7天）内正常工作。一分钟结束后，url无效，不再正常工作

但一旦过期，我会再次运行代码来生成一个新的url。不幸的是，它生成了相同的url，但仍然无效

容器策略的开始/结束时间是否为绝对时间，即我现在设置该策略时：

sharedAccessPolicy.SharedAccessStartTime = DateTime.UtcNow;
sharedAccessPolicy.SharedAccessExpiryTime = DateTime.UtcNow.AddMinutes(1);

---

使用该策略的任何内容仅在今天上午10:10（美国东部时间）到上午10:11（美国东部时间）之间有效？

如果过期1分钟，您可能会遇到SAS生成框和Windows Azure存储之间的时钟偏移效应。你应该用更长的时间间隔。我对共享访问签名进行了深入研究，您可能会发现这很有帮助。

您可以做的一件事是创建无到期日的访问策略。您可以在创建签名URL时指定到期日期

因此，您的代码看起来像：

        SharedAccessPolicy sharedAccessPolicy = new SharedAccessPolicy();
        sharedAccessPolicy.Permissions = SharedAccessPermissions.Read;
        sharedAccessPolicy.SharedAccessStartTime = DateTime.UtcNow;
        //sharedAccessPolicy.SharedAccessExpiryTime = DateTime.UtcNow.AddMinutes(1); No need to define expiry time here.

        BlobContainerPermissions blobContainerPermissions = new BlobContainerPermissions();
        blobContainerPermissions.SharedAccessPolicies.Add("default", sharedAccessPolicy);

        container.SetPermissions(blobContainerPermissions);

        Console.WriteLine("Press any key to continue....");
        Console.ReadLine();
        CloudBlob blob = container.GetBlobReference(path);

        string sas = blob.GetSharedAccessSignature(new SharedAccessPolicy()
        {
            SharedAccessExpiryTime = DateTime.UtcNow.AddDays(7),//add expiry date only when you're creating the signed URL
        }
            , "default");

        Console.WriteLine(blob.Uri.AbsoluteUri + sas);

        Process.Start(new ProcessStartInfo(blob.Uri.AbsoluteUri + sas));

        Console.WriteLine("Press any key to continue....");
        Console.ReadLine();

这对你有用吗？显然，您需要在7天后重新生成URL，但不必对访问策略进行任何更改

---

希望这能有所帮助。

您可能已经达到了容器级访问策略的最大值

存储访问策略包含一个名称，该名称最多64个字符，在容器中是唯一的。此名称出现在链接到存储访问策略的共享访问签名的signedidentifier字段中。一个容器最多可以包含5个存储的访问策略。每个策略可以由任意数量的共享访问签名使用

---

谢谢你的回答。不幸的是，如果您使用的是容器访问策略，则在创建共享访问签名时无法指定任何其他参数。错误是“访问策略字段可以与签名或SAS标识符关联，但不能两者都关联”。我同意。这就是为什么我从访问策略中排除了SharedAccessExpiryTime（我对这行代码进行了注释），并将其包含在已签名的URL中。很抱歉，我错过了注释。这确实有效，并且使我不必重写大量代码。谢谢，做得很好。我只有一个容器级访问策略。我认为答案是我的误解，也就是说，容器策略时间是在创建策略时设置的，而不是在生成URL时设置的。我听到了。但这两条线可能会产生新的政策。检查集合中的计数。这将实质上覆盖blob容器上的任何现有策略。若要保留现有访问策略，您需要在“SharedAccessPolicys”集合中传递它们。@GauravMantri检查集合计数是否会破坏任何内容？否。基本上，如果您希望保留现有访问策略并希望添加更多访问策略（前提是您不超过5的限制），首先获取访问策略，添加新的访问策略，然后使用SetPermission（）方法保存这些策略。但是，如果您只是添加了一个访问策略而没有获取现有策略并保存它，它将覆盖所有现有策略。谢谢您的帖子。不幸的是，无论时间间隔如何，它都会发生。我最初发现它是因为我将时间设置为7天，并且查看提交日志，我在7天前设置了访问策略。我认为问题在于容器策略时间意味着策略创建的时间，而不是URL生成的时间。这很有意义，因为GetSharedAccessSignature（）不进行任何网络调用，所以它不能为策略生成唯一的签名，因为容器策略的开始/结束时间是绝对的。我也认为他们是相对的。