2012-07-18 43 views
7

Azure Blob和共享访问签名过期时遇到问题。我需要授予blob超过1小时(7天)的访问权限,所以我使用了一个命名的容器策略,但不幸的是,我似乎无法在这7天内启动新的Url。Azure Blob容器共享访问签名到期

我有以下代码来创建“默认”策略。注意:此代码,我设置过期从现在开始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网址改为:

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,并在下一分钟(或真正的代码7天)正常工作。一分钟结束后,该网址无效并且不再按预期工作。

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

是集装箱政策开始/结束时间是绝对的,这意味着,当我设置的政策现在:

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

任何使用政策只是从上午10:10(美国东部时间)有效的上午10点11分( EDT)今天?

+0

因此,容器策略的开始/结束时间是绝对的。我也认为他们是相对的。 – nmit026 2017-11-13 04:23:43

回答

9

您可以做的一件事是创建您的访问策略而不失效日期。您在创建签名的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,但不必对访问策略进行任何更改。

希望这会有所帮助。

+1

感谢您的答案。不幸的是,如果您使用容器访问策略,则在创建共享访问签名时不能指定任何其他参数。错误是“访问策略字段可以与签名或SAS标识符关联,但不能同时关联”。 – mfanto 2012-07-18 15:05:48

+0

我同意。这就是为什么我从访问策略中排除了SharedAccessExpiryTime(我评论了该行代码)并将其包含在签名的URL中。 – 2012-07-18 15:10:45

+0

我的歉意,我错过了评论。这确实起作用,并且使我不必重写大块代码。谢谢你,做得很好。 – mfanto 2012-07-18 15:13:13

0

1分钟过期后,您可能会遇到SAS生成框与Windows Azure存储之间的时钟偏斜效应。你应该使用更长的时间间隔。我做了一个post进入共享访问签名的血淋淋的深度,你可能会发现有帮助。

+0

感谢您的帖子。不幸的是,不管时间间隔如何。我最初发现它是因为我将时间设置为7天,并查看提交日志,我在7天前设置了访问策略。我认为问题在于容器策略时间意味着创建策略的时间,而不是生成时间。这是有道理的,因为GetSharedAccessSignature()不进行任何网络调用,它不能为策略生成唯一的签名 – mfanto 2012-07-18 15:09:25

0

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

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

Using a Stored Access Policy

+0

我只有一个容器级访问策略。我认为答案是我的误解,也就是说,容器政策时间是在创建政策时设定的,而不是在生成网址时设定的。 – mfanto 2012-07-18 15:07:56

+0

我听到你的声音。覆盖范围但这两条线可能会产生新的政策。检查收集的数量。再次达到。 – Paparazzi 2012-07-18 15:13:11

+0

@Blam这将基本上覆盖您可能在您的blob容器上的任何现有策略。为了保留现有的访问策略,您需要将它们传递到“SharedAccessPolicies”集合中。 – 2012-07-18 15:20:07

相关问题