后端物联网消息队列通信【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址https://gitcode.com/gh_mirrors/em/emqx点击查看免费下载本篇文章围绕 EMQX 修复项 fix-18196 展开当 API Key 在创建时未显式指定 scope留空随后通过管理 API 读取并把返回值原样回写更新时会触发校验错误。修复后EMQX 将「与角色隐式默认一致的 scope 列表」以及unset哨兵值等价视为「未显式指定 scope」从而让「读-改-写」流程可以正常往返同时这类 Key 会继续使用向前兼容的隐式 scope而不会被固化成一份冻结的列表。读完本文你将理解该 bug 的根因、unset哨兵的设计动机以及如何在实践中正确创建与更新带 scope 的 API Key。一、问题背景API Key 的 scope 与「留空」语义在 EMQX 中API Key 是调用管理 REST API 的凭证可绑定一个角色role并可携带一个显式的权限 scope 列表scopes用于精细控制该 Key 能访问哪些接口。相关端点定义在 emqx_mgmt_api_api_keys.erlPOST /api_key创建 API KeyPUT /api_key/:name更新 API Key名称、过期时间、描述、启用状态、角色、scopeGET /api_key、GET /api_key/:name读取GET /api_key_scopes返回当前 scope 静态目录名称与 i18n 描述。隐式默认 scope当一个 Key 创建时没有提供scopes字段EMQX 并不会真正「留空」而是会在持久化时物化materialize出该角色对应的默认 scope 列表。该逻辑位于 emqx_mgmt_auth.erl 的role_default_scopes/1全局 administrator / viewer物化为?GENERIC_SCOPES10 个管理类 scope不含 login-only scope——后者为 Dashboard 登录用户保留带命名空间namespace的 administrator物化为?NS_ADMIN_COMMON_SCOPES命名空间管理员实际可用的子集尤其不含publish因为 publish API 仅接受全局 API Keypublisher 角色物化为[publish]该角色唯一允许持有的 scope。也就是说「创建时 scope 留空」「隐式采用角色默认 scope」而 GET 返回给调用方的正是这份物化后的默认列表。二、Bug 根因读-改-写往返失败为什么「回写 GET 返回的值」会失败在修复之前存在一个不一致用户创建一个未显式指定 scope 的 Keyscope 留空GET /api_key/:name返回的是物化后的角色默认 scope 列表一个显式的二进制字符串数组用户或自动化脚本把这个数组原样放进PUT /api_key/:name的scopes字段回写——这是最常见的「读-改-写」模式例如仅修改描述后整体提交更新请求把这串列表当作用户主动声明的显式 scope进行校验触发「privilege scope 与普通 scope 不能混用」之类的校验错误见emqx_scope_catalog:check_privilege_scope_mutex/1更新直接失败返回 400。问题本质是服务端「默认值」与「用户显式值」在校验与存储路径上没有区分导致服务端自己吐出的数据无法被合法回写。校验分层validate_scopes/3在 emqx_mgmt_api_api_keys.erl 中实现了四层校验publisher 角色约束validate_publisher_scopes/2publisher 只能持有publishscope或留空/缺省login-only scope 禁令validate_no_login_only_scopes/1API Key 不得持有仅限 Dashboard 登录用户使用的 scopescope 目录校验validate_scopes_in_catalog/1scope 名称必须存在于emqx_scope_catalog否则 400privilege-scope 互斥检查check_privilege_scope_mutex/1作用于客户端实际发送的原始值。关键点在于第 4 层针对的是「客户端实际发送的列表」。角色默认列表本身是 privilege scope 与普通 scope 的混合若把它当作显式提交就会命中互斥校验——这正是修复前回写失败的场景。三、修复方案unset 等价语义修复的核心思想在变更说明中表述得很清楚API key create and update requests now accept a scope list that matches the roles implicit default (and theunsetvalue) as equivalent to no explicit scopes, so re-submitting the value returned by a read no longer fails. Such keys also keep their forward-compatible implicit scopes instead of a frozen list, consistent with Dashboard users.即「与角色隐式默认一致的 scope 列表」与「unset哨兵」都被等价视为「未显式指定 scope」。write_scope_intent把请求值归一化为三种写入意图实现位于 emqx_mgmt_auth.erl 的write_scope_intent/2write_scope_intent(_Role, undefined) - keep; %% 字段省略 - 保持不变 write_scope_intent(_Role, unset) - unset; %% 原子 unset write_scope_intent(_Role, unset) - unset; %% 二进制哨兵 unset write_scope_intent(Role, Scopes) when is_list(Scopes) - case is_role_default_scopes(Role, Scopes) of true - unset; %% 列表与角色默认集合等价 - unset false - {set, Scopes} %% 真正的显式列表 end; write_scope_intent(_Role, Other) - {set, Other}.其中is_role_default_scopes/2emqx_mgmt_auth.erl使用lists:usort做顺序无关的集合比较因此无论 GET 返回的默认列表以何种顺序排列回写都会被识别为 unset 等价而非显式列表。三种意图的落库效果意图语义存储结果keep字段省略保持现状不修改unset清除显式 scope回到角色默认记录中不保存scopes字段{set, L}显式写入列表L逐字保存并走完整校验创建POST与更新PUT两条路径的落地创建路径create_scopes/2emqx_mgmt_api_api_keys.erlscopes字段省略undefined物化角色默认列表并校验后写入unset哨兵原子或unset二进制等价于未指定不落scopes字段显式列表逐字校验后写入。更新路径update_api_key/3emqx_mgmt_api_api_keys.erl结合validate_update_scopes/3emqx_mgmt_api_api_keys.erlunset直接通过清空到角色默认构造上合法keep对持久化的 scope 按可能变化的角色重新校验避免通过部分更新绕过角色约束{set, L}若L与持久化列表角色、namespace 均未变时逐字等价顺序无关见is_unchanged_persisted_scopes/3emqx_mgmt_api_api_keys.erl则原样放行——这是对旧版本遗留 Key 的兼容措施保证「读-改-写」永远可以往返否则按新建时的完整校验路径执行。响应中的unset哨兵修复后当记录中不存在显式scopes字段旧版遗留记录或 unset 等价写入时GET 响应会把scopes以二进制哨兵unset返回见 emqx_mgmt_api_api_keys.erl 的注释与 emqx_mgmt_auth.erl 的format逻辑。请求与响应的 schema 均声明为union([unset, array(binary())])emqx_mgmt_api_api_keys.erl因此客户端可以把 GET 返回值原封不动地回填到 PUT实现真正安全的往返。四、为什么选择「保留隐式默认」而不是「冻结列表」另一个关键设计决策是修复后这类 Key不会把角色默认 scope 物化并固化到持久化记录中而是继续保持「无显式 scope、运行时跟随角色默认」的状态。理由在于向前兼容性若把角色默认列表冻结为显式存储那么后续 EMQX 版本为某角色新增默认 scope 时旧 Key 将永远停留在旧列表上无法自动获得新能力管理员必须逐个手动更新保持「隐式默认」意味着运行时始终解析当前角色默认emqx_mgmt_auth.erl 的get_scopes/1记录无scopes字段时返回undefined即「向后兼容、允许全部」新版本的能力自动对这类 Key 生效。这一行为与Dashboard 登录用户完全一致见 emqx_dashboard_user_scopes_SUITE.erl 中关于默认管理员无显式 scope、保持向前兼容隐式集合的用例修复消除了 API Key 与 Dashboard 用户两套语义之间的差异。五、测试验证往返、哨兵与显式列表仓库中的回归测试位于 emqx_mgmt_api_api_keys_SUITE.erl其中t_ee_scopes_update_unchanged_roundtrip/1L1765-L1783完整复现并验证了 #18196 场景创建一个 scope 留空的 KeyGET 返回物化后的角色默认列表把该列表原样回写 PUT——修复前失败修复后成功且存储被归一化为「无显式 scope」GET 显示unset用unset哨兵再往返一次依旧成功顺序无关把默认列表反序lists:reverse提交同样被识别为 unset 等价从 unset 状态写入一个真正的显式列表如[connections, monitoring]仍然生效并被逐字返回。配套用例还覆盖了POST 直接接受unset哨兵t_ee_scopes_create_unset_sentinelL1789-L1793、显式列表仍逐字校验存储t_ee_scopes_update_explicit_list、publisher 角色「只能持有 publish」的不变式在 unset 等价处理后依然成立t_ee_publisher_update_rejects_explicit_non_publishL1813-L1824以及命名空间管理员遗留 scope 列表的兼容往返t_ee_ns_admin_legacy_publish_scopes_roundtripL1959 附近。六、实践指引正确使用 API Key 的 scopes基于上述语义实际操作时遵循以下原则即可避免踩坑读取后原样回写永远安全GET /api_key/:name返回的scopes无论是数组还是unset哨兵可以直接放入PUT请求体不需要做任何转换或过滤。想用「角色默认」就省略或传unset创建/更新时省略scopes字段或显式传unset/scopes: unset效果等价且保持向前兼容的隐式行为。想收紧权限就传显式列表例如scopes: [connections, monitoring]该列表会被逐字校验并存储此时务必注意 publisher 角色只能持有publish命名空间下的 Key 只能持有?NS_ADMIN_ALLOWED_SCOPES允许的子集。不要手工「补全」默认值如果 GET 返回unset不要自行替换成你以为的角色默认列表再提交——除非该列表与角色默认集合等价顺序无关否则会被当作显式列表走完整校验可能因 privilege-scope 互斥而失败。从unset状态出发做增量修改读取得到unset→ 只改desc/enable等字段 → 回写scopes: unset即完成一次标准的「读-改-写」不会触发校验错误也不会意外冻结 scope。七、总结修复项 fix-18196 解决的并非一个孤立的校验 bug而是理顺了 API Key scope 的「隐式默认」与「显式声明」两套语义通过write_scope_intent/2引入keep/unset/{set, L}三种写入意图把「与角色默认等价的列表」和unset哨兵统一归一化为「无显式 scope」同时保留向前兼容的隐式默认行为并与 Dashboard 用户语义对齐。该修复已随 6.1.4、6.2.3 等版本发布见 changes/6.1.4.en.md 与 changes/6.2.3.en.md 中的对应条目并由完整的回归测试套件保障使得「创建留空 → 读取 → 回写更新」这一高频自动化场景从此稳定可靠。赞分享后端物联网消息队列通信【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址https://gitcode.com/gh_mirrors/em/emqx点击查看免费下载相关推荐EMQX 命名空间 API Key 默认 Scope 对齐修复publish 权限不再被错误授予EMQX 命名空间 API Key 默认 Scope 对齐修复 publish 权限不再被错误授予 本篇技术指南围绕 EMQX 开源仓库中 changes/e后端物联网消息队列通信EMQX Dashboard 用户 API 修复深度解析默认管理员备注编辑报错问题与 scope 隐式继承语义EMQX Dashboard 用户 API 修复深度解析默认管理员备注编辑报错问题与 scope 隐式继承语义 本文基于 EMQX 开源仓库 changes/后端物联网消息队列通信EMQX 默认管理员账户改为隐式角色默认 Scope修复启动时被显式 Scope 列表冻结的问题fix-18221EMQX 默认管理员账户改为隐式角色默认 Scope修复启动时被显式 Scope 列表冻结的问题fix 18221 导读 本文基于 EMQX 仓库变更记录后端物联网消息队列通信上一篇探索神秘的Hierapolis一个基于Bootstrap 3的优雅后台管理模板下一篇推荐开源项目Bikeshed一款强大的规范预处理器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/24 16:29:57 · 阅读 1.2k EMQX API Key 空 Scope 更新报错修复：unset 等价语义与隐式默认 Scope 的取舍
后端物联网消息队列通信【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址https://gitcode.com/gh_mirrors/em/emqx点击查看免费下载本篇文章围绕 EMQX 修复项 fix-18196 展开当 API Key 在创建时未显式指定 scope留空随后通过管理 API 读取并把返回值原样回写更新时会触发校验错误。修复后EMQX 将「与角色隐式默认一致的 scope 列表」以及unset哨兵值等价视为「未显式指定 scope」从而让「读-改-写」流程可以正常往返同时这类 Key 会继续使用向前兼容的隐式 scope而不会被固化成一份冻结的列表。读完本文你将理解该 bug 的根因、unset哨兵的设计动机以及如何在实践中正确创建与更新带 scope 的 API Key。一、问题背景API Key 的 scope 与「留空」语义在 EMQX 中API Key 是调用管理 REST API 的凭证可绑定一个角色role并可携带一个显式的权限 scope 列表scopes用于精细控制该 Key 能访问哪些接口。相关端点定义在 emqx_mgmt_api_api_keys.erlPOST /api_key创建 API KeyPUT /api_key/:name更新 API Key名称、过期时间、描述、启用状态、角色、scopeGET /api_key、GET /api_key/:name读取GET /api_key_scopes返回当前 scope 静态目录名称与 i18n 描述。隐式默认 scope当一个 Key 创建时没有提供scopes字段EMQX 并不会真正「留空」而是会在持久化时物化materialize出该角色对应的默认 scope 列表。该逻辑位于 emqx_mgmt_auth.erl 的role_default_scopes/1全局 administrator / viewer物化为?GENERIC_SCOPES10 个管理类 scope不含 login-only scope——后者为 Dashboard 登录用户保留带命名空间namespace的 administrator物化为?NS_ADMIN_COMMON_SCOPES命名空间管理员实际可用的子集尤其不含publish因为 publish API 仅接受全局 API Keypublisher 角色物化为[publish]该角色唯一允许持有的 scope。也就是说「创建时 scope 留空」「隐式采用角色默认 scope」而 GET 返回给调用方的正是这份物化后的默认列表。二、Bug 根因读-改-写往返失败为什么「回写 GET 返回的值」会失败在修复之前存在一个不一致用户创建一个未显式指定 scope 的 Keyscope 留空GET /api_key/:name返回的是物化后的角色默认 scope 列表一个显式的二进制字符串数组用户或自动化脚本把这个数组原样放进PUT /api_key/:name的scopes字段回写——这是最常见的「读-改-写」模式例如仅修改描述后整体提交更新请求把这串列表当作用户主动声明的显式 scope进行校验触发「privilege scope 与普通 scope 不能混用」之类的校验错误见emqx_scope_catalog:check_privilege_scope_mutex/1更新直接失败返回 400。问题本质是服务端「默认值」与「用户显式值」在校验与存储路径上没有区分导致服务端自己吐出的数据无法被合法回写。校验分层validate_scopes/3在 emqx_mgmt_api_api_keys.erl 中实现了四层校验publisher 角色约束validate_publisher_scopes/2publisher 只能持有publishscope或留空/缺省login-only scope 禁令validate_no_login_only_scopes/1API Key 不得持有仅限 Dashboard 登录用户使用的 scopescope 目录校验validate_scopes_in_catalog/1scope 名称必须存在于emqx_scope_catalog否则 400privilege-scope 互斥检查check_privilege_scope_mutex/1作用于客户端实际发送的原始值。关键点在于第 4 层针对的是「客户端实际发送的列表」。角色默认列表本身是 privilege scope 与普通 scope 的混合若把它当作显式提交就会命中互斥校验——这正是修复前回写失败的场景。三、修复方案unset 等价语义修复的核心思想在变更说明中表述得很清楚API key create and update requests now accept a scope list that matches the roles implicit default (and theunsetvalue) as equivalent to no explicit scopes, so re-submitting the value returned by a read no longer fails. Such keys also keep their forward-compatible implicit scopes instead of a frozen list, consistent with Dashboard users.即「与角色隐式默认一致的 scope 列表」与「unset哨兵」都被等价视为「未显式指定 scope」。write_scope_intent把请求值归一化为三种写入意图实现位于 emqx_mgmt_auth.erl 的write_scope_intent/2write_scope_intent(_Role, undefined) - keep; %% 字段省略 - 保持不变 write_scope_intent(_Role, unset) - unset; %% 原子 unset write_scope_intent(_Role, unset) - unset; %% 二进制哨兵 unset write_scope_intent(Role, Scopes) when is_list(Scopes) - case is_role_default_scopes(Role, Scopes) of true - unset; %% 列表与角色默认集合等价 - unset false - {set, Scopes} %% 真正的显式列表 end; write_scope_intent(_Role, Other) - {set, Other}.其中is_role_default_scopes/2emqx_mgmt_auth.erl使用lists:usort做顺序无关的集合比较因此无论 GET 返回的默认列表以何种顺序排列回写都会被识别为 unset 等价而非显式列表。三种意图的落库效果意图语义存储结果keep字段省略保持现状不修改unset清除显式 scope回到角色默认记录中不保存scopes字段{set, L}显式写入列表L逐字保存并走完整校验创建POST与更新PUT两条路径的落地创建路径create_scopes/2emqx_mgmt_api_api_keys.erlscopes字段省略undefined物化角色默认列表并校验后写入unset哨兵原子或unset二进制等价于未指定不落scopes字段显式列表逐字校验后写入。更新路径update_api_key/3emqx_mgmt_api_api_keys.erl结合validate_update_scopes/3emqx_mgmt_api_api_keys.erlunset直接通过清空到角色默认构造上合法keep对持久化的 scope 按可能变化的角色重新校验避免通过部分更新绕过角色约束{set, L}若L与持久化列表角色、namespace 均未变时逐字等价顺序无关见is_unchanged_persisted_scopes/3emqx_mgmt_api_api_keys.erl则原样放行——这是对旧版本遗留 Key 的兼容措施保证「读-改-写」永远可以往返否则按新建时的完整校验路径执行。响应中的unset哨兵修复后当记录中不存在显式scopes字段旧版遗留记录或 unset 等价写入时GET 响应会把scopes以二进制哨兵unset返回见 emqx_mgmt_api_api_keys.erl 的注释与 emqx_mgmt_auth.erl 的format逻辑。请求与响应的 schema 均声明为union([unset, array(binary())])emqx_mgmt_api_api_keys.erl因此客户端可以把 GET 返回值原封不动地回填到 PUT实现真正安全的往返。四、为什么选择「保留隐式默认」而不是「冻结列表」另一个关键设计决策是修复后这类 Key不会把角色默认 scope 物化并固化到持久化记录中而是继续保持「无显式 scope、运行时跟随角色默认」的状态。理由在于向前兼容性若把角色默认列表冻结为显式存储那么后续 EMQX 版本为某角色新增默认 scope 时旧 Key 将永远停留在旧列表上无法自动获得新能力管理员必须逐个手动更新保持「隐式默认」意味着运行时始终解析当前角色默认emqx_mgmt_auth.erl 的get_scopes/1记录无scopes字段时返回undefined即「向后兼容、允许全部」新版本的能力自动对这类 Key 生效。这一行为与Dashboard 登录用户完全一致见 emqx_dashboard_user_scopes_SUITE.erl 中关于默认管理员无显式 scope、保持向前兼容隐式集合的用例修复消除了 API Key 与 Dashboard 用户两套语义之间的差异。五、测试验证往返、哨兵与显式列表仓库中的回归测试位于 emqx_mgmt_api_api_keys_SUITE.erl其中t_ee_scopes_update_unchanged_roundtrip/1L1765-L1783完整复现并验证了 #18196 场景创建一个 scope 留空的 KeyGET 返回物化后的角色默认列表把该列表原样回写 PUT——修复前失败修复后成功且存储被归一化为「无显式 scope」GET 显示unset用unset哨兵再往返一次依旧成功顺序无关把默认列表反序lists:reverse提交同样被识别为 unset 等价从 unset 状态写入一个真正的显式列表如[connections, monitoring]仍然生效并被逐字返回。配套用例还覆盖了POST 直接接受unset哨兵t_ee_scopes_create_unset_sentinelL1789-L1793、显式列表仍逐字校验存储t_ee_scopes_update_explicit_list、publisher 角色「只能持有 publish」的不变式在 unset 等价处理后依然成立t_ee_publisher_update_rejects_explicit_non_publishL1813-L1824以及命名空间管理员遗留 scope 列表的兼容往返t_ee_ns_admin_legacy_publish_scopes_roundtripL1959 附近。六、实践指引正确使用 API Key 的 scopes基于上述语义实际操作时遵循以下原则即可避免踩坑读取后原样回写永远安全GET /api_key/:name返回的scopes无论是数组还是unset哨兵可以直接放入PUT请求体不需要做任何转换或过滤。想用「角色默认」就省略或传unset创建/更新时省略scopes字段或显式传unset/scopes: unset效果等价且保持向前兼容的隐式行为。想收紧权限就传显式列表例如scopes: [connections, monitoring]该列表会被逐字校验并存储此时务必注意 publisher 角色只能持有publish命名空间下的 Key 只能持有?NS_ADMIN_ALLOWED_SCOPES允许的子集。不要手工「补全」默认值如果 GET 返回unset不要自行替换成你以为的角色默认列表再提交——除非该列表与角色默认集合等价顺序无关否则会被当作显式列表走完整校验可能因 privilege-scope 互斥而失败。从unset状态出发做增量修改读取得到unset→ 只改desc/enable等字段 → 回写scopes: unset即完成一次标准的「读-改-写」不会触发校验错误也不会意外冻结 scope。七、总结修复项 fix-18196 解决的并非一个孤立的校验 bug而是理顺了 API Key scope 的「隐式默认」与「显式声明」两套语义通过write_scope_intent/2引入keep/unset/{set, L}三种写入意图把「与角色默认等价的列表」和unset哨兵统一归一化为「无显式 scope」同时保留向前兼容的隐式默认行为并与 Dashboard 用户语义对齐。该修复已随 6.1.4、6.2.3 等版本发布见 changes/6.1.4.en.md 与 changes/6.2.3.en.md 中的对应条目并由完整的回归测试套件保障使得「创建留空 → 读取 → 回写更新」这一高频自动化场景从此稳定可靠。赞分享后端物联网消息队列通信【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址https://gitcode.com/gh_mirrors/em/emqx点击查看免费下载相关推荐EMQX 命名空间 API Key 默认 Scope 对齐修复publish 权限不再被错误授予EMQX 命名空间 API Key 默认 Scope 对齐修复 publish 权限不再被错误授予 本篇技术指南围绕 EMQX 开源仓库中 changes/e后端物联网消息队列通信EMQX Dashboard 用户 API 修复深度解析默认管理员备注编辑报错问题与 scope 隐式继承语义EMQX Dashboard 用户 API 修复深度解析默认管理员备注编辑报错问题与 scope 隐式继承语义 本文基于 EMQX 开源仓库 changes/后端物联网消息队列通信EMQX 默认管理员账户改为隐式角色默认 Scope修复启动时被显式 Scope 列表冻结的问题fix-18221EMQX 默认管理员账户改为隐式角色默认 Scope修复启动时被显式 Scope 列表冻结的问题fix 18221 导读 本文基于 EMQX 仓库变更记录后端物联网消息队列通信上一篇探索神秘的Hierapolis一个基于Bootstrap 3的优雅后台管理模板下一篇推荐开源项目Bikeshed一款强大的规范预处理器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考