/api/v5/clients/mqtt_93496 请求方法 DELETE 删除后，认证账号信息删除同步删除了。emqx还是会认证成功，数据正常上报

EMQX
1

http://x.x.x.x:18083/api/v5/clients/mqtt_93496 请求方法 DELETE 删除后，认证账号信息同步删除。设备立马重连，emqx还是会认证成功，数据正常上报，如何解决这个问题。
步骤：

  1. 删除设备认证信息
  2. 调/api/v5/clients/请求方法 DELETE
  3. 设备自发重连

如何保障3步骤失败，目前会成功

2

你的认证方式是什么来的？认证信息已经同步删除但设备仍能重连，说明重连时认证链仍返回了成功结果； PS： DELETE /api/v5/clients/{clientid} 只负责断开当前连接。

需要补充下面这些信息：

  • EMQX 具体版本、开源版还是企业版、是否为集群。
  • “访问控制 → 认证”里实际使用的认证方式和数据源：内置数据库、MySQL、PostgreSQL、MongoDB、Redis、HTTP、JWT 还是证书；同时贴出认证链顺序，以及身份字段按 username 还是 clientid。
  • 外部资源缓存是否开启、缓存过期时间配置。MySQL、PostgreSQL、MongoDB、Redis、HTTP 等外部认证结果会按节点缓存，后端记录删除后，在缓存过期或清理前仍可能认证成功；内置数据库不走这个外部资源缓存。
  • 删除认证信息时的请求和响应、设备重连时实际使用的 username/clientid，以及 client.authenticate 相关日志。
    光听描述的话，感觉是缓存还在起作用。
3

EMQX 开源5.6.0
“访问控制 → 认证”里实际使用的认证方式和数据源：MySQL
外部资源缓存是否开启：否
clientId:CQtb0pgm4pu/1jJyFqNHm9HRxjaf
username:01&1jJyFqNHm9HRxjaf&CQtb0pgm4pu

4

缓存已关闭时，如果认证记录确实删除，且认证链没有其他认证器，设备下一次 CONNECT 应该被拒绝；需要查认证查询语句和认证链。

  1. 先核对 MySQL 认证器实际查询的身份字段。你这次的 clientid 和 username 不是同一个值。5.6.0 MySQL 认证器默认用 ${username} 查询，例如：
SELECT password_hash, salt, is_superuser FROM mqtt_user WHERE username = ${username} LIMIT 1;

把 EMQX 配置里的完整 query 贴出来，并在 MySQL 中按设备 CONNECT 使用的 username（不是 clientid）确认查询结果确实为空。如果你是按 clientid 建表或删除，查询必须明确使用 ${clientid}；同时确认没有启用 use_username_as_clientid 导致实际 clientid 被覆盖。(这个可能性比较小）
2. 临时检查认证链。5.6.0 中当前认证器没有命中时会继续下一个认证器；如果认证功能没启用则默认放行。确认“访问控制 → 客户端认证”中 MySQL 已启用，并暂时停用 JWT、内置数据库、HTTP 等其他认证器验证。（以前有用户遇到大部分是这个原因）
3. 验证 DELETE 真的断开的是这条连接。先让设备暂停自动重连或断开网络，然后执行：

curl -i -u admin:<password> http://<host>:18083/api/v5/clients/CQtb0pgm4pu%2F1jJyFqNHm9HRxjaf
curl -i -u admin:<password> -X DELETE http://<host>:18083/api/v5/clients/CQtb0pgm4pu%2F1jJyFqNHm9HRxjaf
curl -i -u admin:<password> http://<host>:18083/api/v5/clients/CQtb0pgm4pu%2F1jJyFqNHm9HRxjaf

DELETE 后、设备尚未重连时，最后一个 GET 应返回 client not found/404；随后放开设备重连，并抓同一时刻的 client.authenticate 日志，确认 username、clientid 及认证结果。
4. 如果 MySQL 查询为空、没有 fallback，仍能认证成功，把 MySQL 认证器配置（尤其完整 query）、DELETE 响应、重连时 MQTT CONNECT 返回码和 EMQX 日志贴出来。仅凭目前信息，最可疑的是删除条件与 ${username} 不一致，或认证链还有其他放行路径。