我正在关注此tutorial:
它提到我应该从ServiceBus的属性中获取IssuerName和IssuerKey。使用VS2012 Server Explorer检查我的ServiceBus时,没有名为IssuerName和IssuerKey的属性。当我使用在线Azure管理控制台并单击连接信息时,我只得到一个不是预期的IssuerName和IssuerKey的连接字符串。
这些价值观在哪里?我正在免费试用,这有关系吗?
这就是我所看到的。
答案 0 :(得分:5)
转到 CONFIGURE 标签,您将看到共享访问策略。为了演示/示例,您可以使用RootManageSharedAccessKey。 但是,这不是最佳做法。 您应该创建适合应用程序的共享访问策略,无论是具有发送权限的客户端,具有发送和侦听权限的服务等等。
示例/教程中也有一个错误(旧版SDK的日期内容)。在QueueConnector.cs文件中,CreateNamespaceManager应该调用CreateSharedAccessSignatureTokenProvider而不是CreateSharedSecretTokenProvider。
顺便说一句,您也可以从连接字符串中获取这些值。您只需要从连接字符串中的其他值中提取它们。
答案 1 :(得分:3)
修改强>
我检查过Microsoft Azure正在将身份验证方法从ACS转移到SAS以获得更好的性能和可管理性,因此从新创建的servicebus的对话框中删除了ACS内容。似乎文档尚未更改。
要与SAS一起使用,好的参考资料为http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-queues/,http://msdn.microsoft.com/en-us/library/dn205161.aspx页面中介绍了更多低级方法。
有关SAS(和旧ACS)的更多信息,请参阅http://msdn.microsoft.com/en-us/library/dn170478.aspx
原版以下
请通过网络浏览器访问Azure门户网站。你可能会发现它。
答案 2 :(得分:3)
最近发生了一项更改,即不会为通过门户创建的新服务总线命名空间自动创建关联的ACS命名空间。如果需要ACS身份验证,则需要通过Management API或Azure PowerShell创建命名空间。我在http://brentdacodemonkey.wordpress.com/2014/08/27/shared-access-signatures-with-azure-service-bus/
写了一些解释