Add "topic_subscribe_filter" field to JWT ACL (or some acl behavior like this) about emqx HOT 21 CLOSED

我在最后 deny 了所有 topic 的订阅和发布

规则是顺序检查的。从第一条开始，一条条对主题进行匹配，主题匹配上了，就按 permission 字段进行 ”allow" 或 “deny”，没匹配上就继续到下一条。

• 你截屏里第三条规则的意思是：“允许订阅 c/+/public_key”。
• 但是你又说：“ 似乎还是可以 subscribe c/+/public_key 的”。

所以我就搞不懂你到底想要达到什么样的效果。

from emqx.

首先介绍一下当前 EMQX 的 ACL 规则：

• 如果一个规则允许订阅 t/1，那么 客户端只能订阅 t/1，但是不能订阅 t/+.
• 如果一个规则允许订阅 t/+，那么 订阅 t/1 和 t/+ 都是允许的。
• 如果一个规则拒绝订阅 eq t/+，那么客户端 可以订阅 t/1，也可以订阅 t/2，等等，但是不允许订阅 t/+

然后看你的需求

如果想要达到：允许订阅 t/1, t/2, .... 但是不能订阅 t/+ 本身。就会需要2条规则（顺序不能乱）。

• 拒绝订阅 eq t/+
• 允许订阅 t/+

from emqx.

不理解是什么小小的bug

呃呃，没什么别的意思，我是觉得 deny 和 allow 的行为应该是对称的，我之前看到你的回复说拒绝订阅 xx 允许订阅xx，想当然以为是对称的行为。。只要我 allow 了xx，最后 deny 所有就行，但是我后来想了一下，这只能说是编程习惯不同，不能说是 bug 。

我是最近开始用 emqx 的，对 ACL 相关的东西不太了解，产生了一些误会，实在是不好意思。

from emqx.

• {"topic": "eq t/+"} matches only t/+ exactly (only applicable for subscribe action).
• {"topic": "t/+"} matches t/1, t/2, ... and t/+ itself.

meaning, you can associate deny permission to eq t/+ topic matching so to reject subscription to t/+.

from emqx.

@zmstone

Sorry, That's not what I want. You didn't understand what I was describing.

from emqx.

换中文吧

from emqx.

@zmstone

一、 前提

ACL 里的 topic 有两个耦合的职责

先理解这一点，一定要理解到这两个耦合的职责，才能理解后面的内容。

另外，我们讨论的问题只在 subscribe 里才有的问题，publish 是不能 publish 到通配符 topic 的

二、 两个耦合的职责

每当有一个 subscribe 进来的时候，会先用 topic 字段检查 subscribe 的字段是否合法，① 可以是等于 topic 的内容，② 也可以是符合 topic 的通配符匹配的规则。

① 可以是等于 topic 的内容

如果 t/+ 可以匹配 t/+

② 也可以是符合 topic 的通配符匹配的规则

如果 t/+ 可以匹配 t/1

三、分开这两个职责

我的目的就是分开这两个职责，topic_subscribe_filter 可以只可以过滤符合规则 topic 的内容，并不会匹配他本身

如果 topic_subscribe_filter 为 t/+ 时，只会匹配 t/1 或者 t/2 。不会匹配到 t/+

四、为什么要这样？

还是拿产品列表，产品详情来举例，我们知道产品的列表权限和产品的详情权限一定是两个不同的权限。

并且两者消耗的资源也不一样，列表权限耗费的资源会更多，通过ID获取详情耗费的资源更少（通过索引可以直接获取到物理地址）

同样的，在topic subscribe里，subscribe t/+ 可以理解为获取产品列表，subscribe t/1 可以理解为获取产品详情，消耗的资源也不一样，并且在含有 retain 字段的主题里，这将会是性能灾难。。一不小心subscribe 到 t/#时，持久化的所有 message 都会一股脑的发过来。

我已经尽量简化我的描述，我不知道我这样说是不是好理解。

from emqx.

我在文档里看到描述是这样的。我晚些时候测试下 eq 是什么行为

“为了避免占位符跟想要的主题冲突的问题，EMQX 5.0 中引入了一个 eq 语法，例如 eq a/b/${username}/c/d”

“To avoid placeholder interpolation, one may use special eq syntax: eq a/b/${username}/c/d. This topic is treated as a/b/${username}/c/d literally, without interpolation.”

from emqx.

我在文档里看到描述是这样的。我晚些时候测试下 eq 是什么行为

“为了避免占位符跟想要的主题冲突的问题，EMQX 5.0 中引入了一个 eq 语法，例如 eq a/b/${username}/c/d”

“To avoid placeholder interpolation, one may use special eq syntax: eq a/b/${username}/c/d. This topic is treated as a/b/${username}/c/d literally, without interpolation.”

文档没有写错，是没写全，想要表达的意思是，eq 规则不会进行模版替换，但是不影响 eq 的表达 “严格匹配” 的意思。
我来修改一下。

from emqx.

emqx/emqx-docs#2544

from emqx.

似乎还是可以 subscribe c/+/public_key 的，还是我的acl 写错了？

from emqx.

eyJhbGciOiJFUzI1NiJ9.eyJzdWIiOiJlNThkNmM1Ny1kY2UyLTQ3NDMtYjliOC1mYTIwZDYwNTMyNDAiLCJhY2wiOlt7InBlcm1pc3Npb24iOiJhbGxvdyIsImFjdGlvbiI6InB1Ymxpc2giLCJ0b3BpYyI6ImMvZTU4ZDZjNTctZGNlMi00NzQzLWI5YjgtZmEyMGQ2MDUzMjQwL3NlbmRfdG8vKyJ9LHsicGVybWlzc2lvbiI6ImFsbG93IiwiYWN0aW9uIjoicHVibGlzaCIsInRvcGljIjoiYy9lNThkNmM1Ny1kY2UyLTQ3NDMtYjliOC1mYTIwZDYwNTMyNDAvcHVibGljX2tleSIsInJldGFpbiI6dHJ1ZX0seyJwZXJtaXNzaW9uIjoiYWxsb3ciLCJhY3Rpb24iOiJzdWJzY3JpYmUiLCJ0b3BpYyI6ImVxIGMvKy9wdWJsaWNfa2V5In0seyJwZXJtaXNzaW9uIjoiYWxsb3ciLCJhY3Rpb24iOiJzdWJzY3JpYmUiLCJ0b3BpYyI6ImMvKy9zZW5kX3RvL2U1OGQ2YzU3LWRjZTItNDc0My1iOWI4LWZhMjBkNjA1MzI0MCJ9LHsicGVybWlzc2lvbiI6ImRlbnkiLCJhY3Rpb24iOiJhbGwiLCJ0b3BpYyI6IiMifV0sImlhdCI6MTcxODQ1NDIwMywiaXNzIjoidXJuOmhlbWE6bXF0dC1hdXRoOnJhbmRvbV90b2tlbiIsImF1ZCI6InVybjpoZW1hOm1xdHQiLCJleHAiOjE3MTg1NDA2MDN9.w6a2W7ZZGXg_xoEctYLV59nh4w0hZ2oYkbxbOyojSavHHfogULhdvnpKQAy-_lBtrJOxBj1wpwAwg-tGrQhYPg

上面这是接收消息的token，你可以用 https://jwt.io/ 测试下
下面这是发送 public_key 的 token

eyJhbGciOiJFUzI1NiJ9.eyJzdWIiOiI2ZTgyZTYzZC01OGIxLTQwOTUtYTI5MS0yNmU4ZGQ2N2FkZTIiLCJhY2wiOlt7InBlcm1pc3Npb24iOiJhbGxvdyIsImFjdGlvbiI6InB1Ymxpc2giLCJ0b3BpYyI6ImMvNmU4MmU2M2QtNThiMS00MDk1LWEyOTEtMjZlOGRkNjdhZGUyL3NlbmRfdG8vKyJ9LHsicGVybWlzc2lvbiI6ImFsbG93IiwiYWN0aW9uIjoicHVibGlzaCIsInRvcGljIjoiYy82ZTgyZTYzZC01OGIxLTQwOTUtYTI5MS0yNmU4ZGQ2N2FkZTIvcHVibGljX2tleSIsInJldGFpbiI6dHJ1ZX0seyJwZXJtaXNzaW9uIjoiYWxsb3ciLCJhY3Rpb24iOiJzdWJzY3JpYmUiLCJ0b3BpYyI6ImVxIGMvKy9wdWJsaWNfa2V5In0seyJwZXJtaXNzaW9uIjoiYWxsb3ciLCJhY3Rpb24iOiJzdWJzY3JpYmUiLCJ0b3BpYyI6ImMvKy9zZW5kX3RvLzZlODJlNjNkLTU4YjEtNDA5NS1hMjkxLTI2ZThkZDY3YWRlMiJ9LHsicGVybWlzc2lvbiI6ImRlbnkiLCJhY3Rpb24iOiJhbGwiLCJ0b3BpYyI6IiMifV0sImlhdCI6MTcxODQ1NDM2MiwiaXNzIjoidXJuOmhlbWE6bXF0dC1hdXRoOnJhbmRvbV90b2tlbiIsImF1ZCI6InVybjpoZW1hOm1xdHQiLCJleHAiOjE3MTg1NDA3NjJ9.HkUYnTaRApMuhczyfIZzrvQEgrlT8A9F99oYSM_5XQRaYmTU6qOHfou-NrgF94j_XYgnjKhCdLvAp_LoQE1SVg

from emqx.

似乎还是可以 subscribe c/+/public_key 的，还是我的acl 写错了？

permission 是 allow，所以是允许的。要拒绝的话写 deny

from emqx.

我在最后 deny 了所有 topic 的订阅和发布

from emqx.

我在最后 deny 了所有 topic 的订阅和发布

规则是顺序检查的。从第一条开始，一条条对主题进行匹配，主题匹配上了，就按 permission 字段进行 ”allow" 或 “deny”，没匹配上就继续到下一条。

• 你截屏里第三条规则的意思是：“允许订阅 c/+/public_key”。
• 但是你又说：“ 似乎还是可以 subscribe c/+/public_key 的”。

所以我就搞不懂你到底想要达到什么样的效果。

就是上图这个效果，我想达到的是

1. 允许 subscribe c/2e675e85-9a85-4ef4-8608-14db0f356931/public_key， 这里的 uuid 代指系统中的任何一个用户的ID。动态的无法提前知道，类比产品详情理解，通过ID获取详情
2. 拒绝 subscrube c/+/public_key， 类比产品列表

就是不允许通配符匹配

from emqx.

我又看了一遍这个规则，是不是应该先 deny eq c/+/public_key, 再 allow c/+/public_key 再 deny all topic?

我试试回来看看

from emqx.

我又看了一遍这个规则，是不是应该先 deny eq c/+/public_key, 再 allow c/+/public_key 再 deny all topic?

我试试回来看看

可以了，可算是解决了，eq 目前看来是在 deny 时有用

虽然我们理解问题上下文不一样所以会有些沟通上的问题。

非常感谢你的耐心！

from emqx.

我的理解是类似一个网兜，eq c/+/public_key 就是匹配 c/$uuid/public_key , 在我 allow 和 deny 都会只匹配 c/$uuid/public_key ， 未匹配就会走到后面一步

现在是 eq c/+/public_key 在allow里是allow c/+/public_key + c/$uuid/public_key , deny 里是 deny c/+/public_key 但不管 c/$uuid/public_key 里的规则，这个规则会掉到后面的权限验证来管理。。

from emqx.

from emqx.

我又看了一遍这个规则，是不是应该先 deny eq c/+/public_key, 再 allow c/+/public_key 再 deny all topic?

这个我上面已经解释过了。

如果想要达到：允许订阅 t/1, t/2, .... 但是不能订阅 t/+ 本身。就会需要2条规则（顺序不能乱）。

• 拒绝订阅 eq t/+
• 允许订阅 t/+

from emqx.

不理解是什么小小的bug

from emqx.