Azure 事件中心 REST API：为什么在发送事件时在 URL 中指定发布者？
Azure Event Hubs REST API: Why specify the publisher in the URL when sending events?
Send Event 的 Azure Events Hubs REST API 文档指定 POST 的请求 URI 可以是：
https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/messages
或：
https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/publishers/{deviceId}/messages
使用我们为发布者指定 deviceId 的后一个 URI 模板有什么价值？
TLDR：大型发件人 authorization/identification。
发布商政策旨在实现强大的场景。让我解释一下。
我们有 2 个实体在这里发挥作用：
- 拥有 eventhub 的人（可以说是设备制造商）。这个人有兴趣接收消息并处理它们并从中提取有趣的信息（例如 - 检测设备已准备好进行维修等）
- 发件人（比方说，(1) 人 - 制造设备并销售它们；他嵌入代码以定期将事件推送到云端；所以我们的 (2) 是将事件发送到 eventHub 的实际设备）。
假设您有 100K 个这样的设备 - 将遥测数据发送到 EventHub。比方说，在 EventHub 接收器上，您正在计算来自每台设备的消息数量（并使用它来启用关键场景 - 例如：根据使用情况为每台设备计费）。让我们看看这些 URI 是如何发挥作用以实现这种情况的：
- 使用 Uri1 [https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/messages] - 为了能够发送到 EventHub - 他们需要一个 AuthorizationToken。每个设备不可能维护 100k sas 密钥（并且 EventHubs 最多支持 12 个 SAS 密钥）。所以 (1) - 设备制造商为他的所有设备生成一个令牌 - 使用 GetSharedAccessSignature API & will stuff-in device id inside the message. This token has access to send any message to eventHub. The drawbacks with this approach are, if there is a device2 which finds out how you bill them - it could simply spoof as device1 - by stuffing in a different name. If one device is hacked they will gain access to the entire eventhub. Overall this device has much higher privilege than what is needed and violates principle of least privilege.
- 如果您使用 Uri2 (https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/publishers/{deviceId}/messages) - 以便能够安全地发送到 EventHub - 设备需要授权令牌。因此，设备制造商发布了一个特定于此 {deviceId} url 的令牌（使用 GetPublisherSAS). Now that, the device has access only to this device specific resource Uri, the only operation this device could achieve with the key EVER - is to Send to its own url. In addition to that - if the device manufacturer ever wants to block this device from sending events - it can issue a revokePublisher - 从这一点开始该设备将被阻止。这就是他们管理安全性的方式-大规模发送者级别（以100k为单位）.
我选择了设备制造商作为示例。此功能在许多情况下都非常方便 - 例如：一个拥有约 500 台机器的大型云服务将所有关键遥测事件 写入 eventHubs，一个 大型网站 -从客户端脚本执行每个客户的操作 等..
喂！
斯里
Send Event 的 Azure Events Hubs REST API 文档指定 POST 的请求 URI 可以是：
https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/messages
或：
https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/publishers/{deviceId}/messages
使用我们为发布者指定 deviceId 的后一个 URI 模板有什么价值？
TLDR：大型发件人 authorization/identification。
发布商政策旨在实现强大的场景。让我解释一下。 我们有 2 个实体在这里发挥作用：
- 拥有 eventhub 的人（可以说是设备制造商）。这个人有兴趣接收消息并处理它们并从中提取有趣的信息（例如 - 检测设备已准备好进行维修等）
- 发件人（比方说，(1) 人 - 制造设备并销售它们；他嵌入代码以定期将事件推送到云端；所以我们的 (2) 是将事件发送到 eventHub 的实际设备）。
假设您有 100K 个这样的设备 - 将遥测数据发送到 EventHub。比方说，在 EventHub 接收器上，您正在计算来自每台设备的消息数量（并使用它来启用关键场景 - 例如：根据使用情况为每台设备计费）。让我们看看这些 URI 是如何发挥作用以实现这种情况的：
- 使用 Uri1 [https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/messages] - 为了能够发送到 EventHub - 他们需要一个 AuthorizationToken。每个设备不可能维护 100k sas 密钥（并且 EventHubs 最多支持 12 个 SAS 密钥）。所以 (1) - 设备制造商为他的所有设备生成一个令牌 - 使用 GetSharedAccessSignature API & will stuff-in device id inside the message. This token has access to send any message to eventHub. The drawbacks with this approach are, if there is a device2 which finds out how you bill them - it could simply spoof as device1 - by stuffing in a different name. If one device is hacked they will gain access to the entire eventhub. Overall this device has much higher privilege than what is needed and violates principle of least privilege.
- 如果您使用 Uri2 (https://{serviceNamespace}.servicebus.windows.net/{eventHubPath}/publishers/{deviceId}/messages) - 以便能够安全地发送到 EventHub - 设备需要授权令牌。因此，设备制造商发布了一个特定于此 {deviceId} url 的令牌（使用 GetPublisherSAS). Now that, the device has access only to this device specific resource Uri, the only operation this device could achieve with the key EVER - is to Send to its own url. In addition to that - if the device manufacturer ever wants to block this device from sending events - it can issue a revokePublisher - 从这一点开始该设备将被阻止。这就是他们管理安全性的方式-大规模发送者级别（以100k为单位）.
我选择了设备制造商作为示例。此功能在许多情况下都非常方便 - 例如：一个拥有约 500 台机器的大型云服务将所有关键遥测事件 写入 eventHubs，一个 大型网站 -从客户端脚本执行每个客户的操作 等..
喂！ 斯里