listmonk 如何创建受限用户角色并配合 List roles 控制列表级权限

listmonk 如何创建受限用户角色并配合 List roles 控制列表级权限【免费下载链接】listmonkHigh performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.项目地址: https://gitcode.com/GitHub_Trending/li/listmonk当你给团队成员或外部系统开放 listmonk 时通常不希望对方拥有全部功能运营人员只需要查看某个列表的订阅者而程序集成只需要读写指定列表。listmonkv4.0.0 及以上版本通过两套机制完成这件事User role用户角色授予功能级权限List role列表角色授予按列表划分的 view/manage 权限两者同时绑定到用户账号后该用户在 Admin UI 和 API 中只能访问列表角色里定义的列表。本文的任务是创建一个功能权限收窄的用户角色再创建一个只覆盖指定列表的列表角色并把它绑定到新建用户上。前置条件一个已安装运行的 listmonk 实例权限体系要求 v4.0.0。一个具备roles:manage权限的账号来创建角色具备users:manage权限的账号来创建用户。文档明确提示users:manage允许创建拥有任意角色包括 Super Admin的用户应只授予 Super Admin 级别的账号因此这一步建议直接用 Super Admin 操作。角色管理入口在Admin - Users - User roles见 roles-and-permissions.md。创建受限的 User role在Admin - Users - User roles中新建角色然后按最小原则勾选权限。完整的权限清单在文档的权限表中按组划分这里列出创建受限角色时最常涉及的几项原文见 roles-and-permissions.md组权限作用listslists:get_all获取所有列表的详情listslists:manage_all创建、更新、删除所有列表subscriberssubscribers:get/subscribers:get_all/subscribers:manage查看/管理订阅者subscriberssubscribers:sql_query对订阅者数据执行原始 SQL 查询campaignscampaigns:get/campaigns:manage查看/管理所属许可列表的活动bouncesbounces:get/bounces:manage查看/处理退信mediamedia:get/media:manage查看/管理媒体文件templatestemplates:get/templates:manage查看/管理邮件模板usersusers:manage、roles:manage管理用户账号、管理角色创建受限角色时有三项权限需要特别注意文档对它们都有明确警告lists:get_all/lists:manage_all这两个权限会覆盖并凌驾于 List role 中的所有按列表权限。如果你的目标就是只能看指定列表就不能勾选它们否则 List role 的边界形同虚设。subscribers:sql_query允许执行任意 SQL 表达式。虽然是只读事务但可以绕过单条列表/订阅者权限直接查询数据库中的所有列表和订阅者还可能读取 Postgres 数据库配置。文档要求只授予完全信任的用户。users:manage可以创建拥有任意角色含 Super Admin的用户应只保留在 Super Admin 级账号上。如果确实需要给多名用户subscribers:sql_query文档建议在 Postgres 侧额外创建一个禁用特权操作的数据库角色来兜底文档示例其中...替换为你自行设置的数据库密码CREATE ROLE listmonk_app WITH LOGIN PASSWORD ... NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;创建 List role 并指定列表级权限在Admin - Users - User roles中新建一个 List role。List role 的权限粒度是每个列表 每列表两个权限list:getview只读该列表list:manage可更新该列表。操作方式在 List role 编辑表单中从下拉框选择一个列表点击 Add然后在该列表行上勾选 view / manage再逐个添加需要授权的列表。两个边界条件已归档status: archived的列表默认不出现在角色选择器中见 lists API 文档如需要可带statusarchived过滤后再处理如果同一个用户的 User role 里已经勾了lists:get_all或lists:manage_all管理界面会在 List role 表单中显示警告提示全量列表权限会覆盖按列表的权限——这再次确认了第 1 步中不勾选这两项的必要性。创建用户并绑定两个角色在Admin - Users中创建用户账号。用户表单中需要为账号选择 User role必填和 List role可留空留空表示不限制也不授权任何按列表权限仅靠 User role 生效。账号类型有两种见 UserForm 表单regular user用用户名 密码或已连接 OIDC 提供方时用 OIDC 握手登录适合人API user不走密码系统自动生成一个 secret token创建时一次性展示适合程序调用 listmonk 的 HTTP API。如果这条路径是给外部系统用的选 API user 并妥善保存 token给人用的就选 regular user。验证权限边界文档给出的权限生效条件是Only the lists defined in a list role is accessible by the user, be it on the admin UI or via API calls. 也就是说无论走界面还是 API用户都只能碰到 List role 里列出的列表。可以按下面两种方式核对UI 验证用受限账号登录在列表页确认只能看到 List role 中授权的列表并且未勾选的权限对应的功能入口如 campaigns 的创建按钮不可用。API 验证用受限 API user 的 token 请求列表接口命令取自 apis.mdcurl -u api_user:token http://localhost:9000/api/lists其中api_user:token替换为你创建 API user 时的用户名和一次性 tokenlocalhost:9000按你的实例地址和端口替换。返回的 JSON 中data.results应只包含 List role 授权范围内的列表。API 认证也支持Authorization: token api_user:token请求头的方式见同一文档。请求失败时API 会返回 40x/50x 状态码加 JSON 错误体如 400 参数错误、404 资源不存在完整的状态码含义表在 apis.md 中。限制与后续lists:get_all/lists:manage_all与 List role 互斥生效前者一旦授予按列表的权限就失去意义。改角色权限时把这两项和 List role 放在一起核对。角色 ID 1Super Admin 角色是保留的不能通过更新或删除接口修改见 cmd/roles.go 中auth.SuperAdminRoleID的拦截逻辑管理界面中该角色表单同样被禁用。角色本身也可以通过 API 管理GET/POST /api/roles/users、GET/POST /api/roles/lists、PUT /api/roles/users/:id、PUT /api/roles/lists/:id、DELETE /api/roles/:id均要求调用方具备roles:manage权限路由定义见 cmd/handlers.go。如果你希望用脚本批量维护受限角色而不是走 UI可以直接调用这些接口权限校验规则与文档一致。授权subscribers:sql_query的用户不受上述列表边界保护这是文档明确声明的行为而非遗漏对这类用户Postgres 侧的自定义角色是文档给出的缓解手段。【免费下载链接】listmonkHigh performance, self-hosted, newsletter and mailing list manager with a modern dashboard. Single binary app.项目地址: https://gitcode.com/GitHub_Trending/li/listmonk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考