运维观测指标监控告警【免费下载链接】falcon-plusAn open-source and enterprise-level monitoring system.项目地址https://gitcode.com/gh_mirrors/fa/falcon-plus点击查看免费下载导读用户列表接口是 Open-Falcon Plus 平台用户管理模块UICUser Identity Center中最基础也最常用的查询入口用于枚举系统中全部用户及其角色、联系方式等信息。本文以 docs/_posts/User/2017-01-01-user_list.md 文档为主体结合仓库中 API 模块的源码实现路由注册、控制器、数据模型、会话校验与数据库表结构完整讲解该接口的调用方式、请求约束、分页与过滤参数、响应字段语义及常见错误处理让读者能够直接对接该接口进行用户管理系统的二次开发或运维排查。接口概览项目说明请求方式GET接口路径/api/v1/user/users功能返回系统中全部用户列表鉴权要求需要有效 Session会话成功状态码200数据来源MySQLuic库中的user表该接口在 API 模块中由 modules/api/app/controller/uic/user_routes.go 注册路由挂在/api/v1/user分组下并挂载了AuthSessionMidd会话校验中间件authapi : r.Group(/api/v1/user) authapi.Use(utils.AuthSessionMidd) authapi.GET(/users, UserList)也就是说所有对/api/v1/user/users的请求都会先经过会话校验只有携带合法 Session 的请求才能拿到用户列表。会话Session鉴权机制原文档第一行明确指出* [Session](#/authentication) Required即调用该接口必须携带有效会话凭证。会话校验的完整链路如下请求头中携带Apitoken其值为一段 JSON 字符串形如{name:root,sig:427d6803b78311e68afd0242ac130006}modules/api/app/helper/session.go 中的GetSession解析该 JSON校验name与sig是否为空SessionChecking先检查default_token配置项用于服务端内部调用再以name查user表、以sig uid查session表均命中才判定鉴权通过modules/api/app/utils/auth_middle.go 中的AuthSessionMidd中间件在鉴权失败时返回401 Unauthorized并中断请求。需要注意一个配置开关当 modules/api/cfg.example.json 中的skip_auth设为true时中间件会跳过校验此时无需 Session 也可访问该接口——这通常只用于本地调试或测试环境。此外服务端内部调用可借助default_token配置default_token非空且 sig 与之相等即视为合法便于服务端脚本免登录调用 API。请求参数与分页过滤虽然原文档只展示了基本调用但源码中 modules/api/app/controller/uic/user_controller.go 的UserList实现表明该接口支持三个可选的 Query 参数用于控制返回规模和过滤范围参数类型默认值说明pageint空不分页页码从 1 开始设置后必须同时设置limitlimitint空不分页每页返回条数qstring.按用户名name正则过滤的正则表达式默认匹配所有非空名称分页语义分页参数由 modules/api/app/helper/pagging_parser.go 中的PageParser解析其规则为page与limit均未设置不分页返回全部用户只设置page未设置limit报错You set page but skip limit params, please check your input任一参数小于等于 0报错limit or page can not set to 0 or less than 0page 1时实际偏移量换算为 0其他页码按(page-1) * limit计算偏移。分页模式下底层执行的原生 SQL 为select * from user where name regexp ? limit ?,?对应的 Go 实现片段if limit ! -1 page ! -1 { dt db.Uic.Raw(select * from user where name regexp ? limit ?,?, q, page, limit).Scan(user) } else { dt db.Uic.Table(user).Where(name regexp ?, q).Scan(user) }正则过滤示例借助q参数可按用户名正则模糊匹配例如# 返回所有用户名默认行为 curl -G http://localhost:8080/api/v1/user/users \ -H Apitoken: {\name\:\root\,\sig\:\你的sig\} # 按正则过滤只返回以 test 开头的用户 curl -G http://localhost:8080/api/v1/user/users \ -H Apitoken: {\name\:\root\,\sig\:\你的sig\} \ --data-urlencode q^test # 分页返回第 2 页每页 10 条 curl -G http://localhost:8080/api/v1/user/users \ -H Apitoken: {\name\:\root\,\sig\:\你的sig\} \ --data-urlencode page2 --data-urlencode limit10响应结构与字段语义接口成功返回200响应体为一个 JSON 数组数组元素对应user表中的一条用户记录。原文档给出的示例响应如下[ { id: 1, name: root, cnname: , email: , phone: , im: , qq: 904394234239, role: 2 }, { id: 32, name: owltester, cnname: 翱鶚, email: root123cepave.com, phone: 99999999999, im: 44955834958, qq: 904394234239, role: 0 } ]各字段的定义可以直接对照 modules/api/app/model/uic/user.go 中的数据模型字段类型说明idint64用户唯一 IDuser表主键自增namestring登录用户名唯一索引cnnamestring中文名 / 显示名emailstring邮箱phonestring手机号imstring即时通讯账号qqstringQQ 号roleint用户角色详见下文值得注意的是模型中的Passwd字段带有json:-标签意味着密码永远不会出现在任何 API 响应中从数据模型层面保证了密码不外泄。role 字段用户角色语义role的取值定义在 scripts/mysql/db_schema/1_uic-db-schema.sql 的建表注释中role: -1:blocked 0:normal 1:admin 2:root值角色权限说明-1blocked被封禁用户无法正常使用系统0normal普通用户1admin管理员2root超级管理员root结合 modules/api/app/model/uic/user.go 中的IsAdmin/IsSuperAdmin方法可以确认role为 1 或 2 均视为管理员role 2才视为超级管理员。示例响应中root用户role: 2、普通用户owltesterrole: 0正好与语义一致。另外注意仅当配置access_control为true时才执行角色校验见skipAccessControll函数若关闭该开关则所有用户都被视为管理员生产环境请保持开启。真实调用记录参考仓库中的接口采集文档 docs/doc/user.html.json 记录了该接口的一次真实调用请求头携带Cookie: nametest1; sig...即通过 Cookie 携带会话返回200及包含多个用户的完整列表其中既有role: 2的 root、role: 1的管理员用户id 14也有大量role: 0的普通用户可以用于对照理解响应格式与角色字段的真实取值。更多接口示例可参考 docs/doc/user.html错误码约定参见 docs/_posts/2017-01-01-response-status-codes.md。常见错误与排查场景返回说明未携带或携带非法 Session401 Unauthorized由AuthSessionMidd中间件拦截错误信息形如token key is not set、session not found设置了page但未设置limit400 Bad Request提示You set page but skip limit paramspage或limit小于等于 0400 Bad Request提示limit or page can not set to 0 or less than 0page/limit非法数值400 Bad Request字符串无法转换为整数时同样报 400数据库查询异常417 Expectation Failed底层 SQL 执行出错时返回排查建议先确认是否已通过POST /api/v1/user/login登录并拿到sig登录接口示例见 docs/doc/user.html.json 中/api/v1/user/login的记录再检查 API 模块配置文件中的skip_auth与default_token是否符合预期最后确认uic库连接与user表数据是否正常连接串配置位于 modules/api/cfg.example.json 的db.uic项。总结GET /api/v1/user/users是 Open-Falcon Plus 用户管理 API 中最基础的查询接口。通过本文可以掌握接口的会话鉴权链路Apitoken头 →AuthSessionMidd→session表校验、page/limit/q三个查询参数的分页与正则过滤用法、响应数组各字段与role角色取值语义以及基于源码定位各类错误原因的方法。该接口与 docs/_posts/User/2017-01-01-user_get_info_by_id.md、docs/_posts/User/2017-01-01-user_login.md 等文档共同构成完整的用户管理 API 体系可作为前端页面与运维脚本对接用户数据的标准入口。赞分享运维观测指标监控告警【免费下载链接】falcon-plusAn open-source and enterprise-level monitoring system.项目地址https://gitcode.com/gh_mirrors/fa/falcon-plus点击查看免费下载相关推荐Open-Falcon 用户信息查询 API 实战GET /api/v1/user/u/{user_id} 接口详解Open Falcon 用户信息查询 API 实战GET /api/v1/user/u/{user_id} 接口详解 本文以 Open Falconfalc运维观测指标监控告警Open-Falcon Falcon 用户登出接口实战GET /api/v1/user/logout 的原理、调用与 Session 清理Open Falcon Falcon 用户登出接口实战GET /api/v1/user/logout 的原理、调用与 Session 清理 导读 本文以 O运维观测指标监控告警Open-Falcon falcon-plus API 实战向 Team 批量添加用户POST /api/v1/team/userOpen Falcon falcon plus API 实战向 Team 批量添加用户POST /api/v1/team/user 本文是 falcon运维观测指标监控告警上一篇trouble.nvim革命从诊断工具到开发者文化符号下一篇如何构建田间鲁棒的植物病害检测系统PlantDoc数据集完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考