人工智能计算机视觉后端AI 应用【免费下载链接】CompreFaceLeading free and open-source face recognition system项目地址https://gitcode.com/gh_mirrors/co/CompreFace点击查看免费下载CompreFace 采用「全局角色 应用角色」的双层权限模型来管理多租户场景下的用户访问控制全局角色决定你在系统本身的运维能力应用角色决定你在具体某个集成应用内的操作权限。阅读本文你将掌握两套角色owner / administrator / user各自的权限边界、默认分配规则与自删保护等关键限制并能对照 Java 后端源码枚举定义、授权管理器、服务层逻辑验证这些权限规则在代码中的真实落地方式。角色体系总览CompreFace 的角色系统由两种角色类型组成全局角色Global Roles定义用户在系统本身中的权限这类用户的主要职责是维护系统本身应用角色Application Roles定义用户在某个应用内的权限这类用户的主要职责是开发将集成 CompreFace 的应用。官方建议拥有高权限owner、administrator的用户应与业务敏感数据隔离即运维人员不必加入具体应用——因为他们本就已拥有应用内的全部权限。当然小团队可以自行权衡、忽略这些建议。在源码中这两套角色分别由两个枚举定义且各含三个等级枚举取值单字母编码GlobalRoleOWNER、ADMINISTRATOR、USERO、A、UAppRoleOWNER、ADMINISTRATOR、USERO、A、U对应文件为 GlobalRole.java 和 AppRole.java。两者都实现了EnumCode接口code字段用于在接口参数中传递简化的角色编码。全局角色Global Roles全局角色定义用户对系统本身的权限主要职责是维护系统。官方推荐将最宽泛的角色owner 和 administrator授予技术支持/运维人员——因为这类用户加入应用后也没有额外收益其权限已覆盖应用内一切操作。Global Owner系统最高权限与唯一限制在 CompreFace 中第一个注册用户会自动获得全局 owner 角色拥有系统内任意操作的权限管理用户、创建和管理应用。Owner 唯一的限制是不能删除自己。因此 owner 若要从系统中退出必须先把自己 owner 角色移交给别人然后再删除自己。这一点在源码中得到印证AuthorizationManager.java 中的verifyCanDeleteUser方法对全局 owner 直接抛出InsufficientPrivilegesException(Global owner cannot be removed!)UserService.java 中的decideNewOwner逻辑处理删除 owner 时的新 owner 归谁问题自删selfRemoval时 owner 归属保持为系统内现有的 owner否则根据ReplacerDELETER或其他决定由删除者还是全局 owner 接管当全局 owner 被通过移交流程转交时AppService.java 的passAllOwnedAppsToNewOwnerAndLeaveAllApps会把原 owner 名下所有应用移交给新用户并保留其在各应用中的AppRole.OWNER身份。Global Administrator与 Owner 几乎等权全局 administrator 的权限与全局 owner 相同唯一差别是不能管理全局 owner 用户。官方建议将此类角色用户数量缩减到维护系统所需的最少人数。源码中这一降权体现在可分配角色的计算上见 UserService.java 的getGlobalRolesToAssign当前操作者是OWNER时可分配全部角色GlobalRole.values()当前操作者是ADMINISTRATOR时只能分配ADMINISTRATOR和USER——即无法把用户设为 owner也无法对 owner 进行角色管理。Global User默认角色所有新注册用户自动获得全局 user 角色。这类用户不能创建应用只能访问被显式加入的应用不能管理其他用户。他们的定位是使用 CompreFace 做人脸识别的开发者开发团队成员而非其他用户与权限的管理者。从源码看这一只能看自己加入的应用的行为由 AppService.java 的getApps方法实现当用户全局角色为USER时查询限定为findAllByUserAppRoles_Id_UserId(userId)仅返回其有应用角色的应用其他角色owner/administrator则返回全部应用findAllByOrderByNameAsc()。应用角色Application Roles应用角色定义用户在某个具体应用内的权限这类用户的主要职责是开发集成 CompreFace 的应用。官方推荐最宽泛的应用角色owner 和 administrator应授予项目经理与团队负责人因为他们对应用负责所有应用用户都应同时具备全局 user 角色全局 user 角色用户要加入应用团队必须由全局 owner、全局 administrator 或应用 owner 将其直接加入应用。App Owner应用内的最高权限创建应用的用户自动获得该应用的 owner 角色拥有应用内的全部操作权限管理应用本身及其应用用户、创建并管理 Face Services。与全局 owner 一样应用 owner 的唯一限制是不能把自己从该应用中删除——必须先转让 owner 角色才能自行退出。AuthorizationManager.java 中的verifyUserDeletionFromApp方法精确编码了这一规则若删除者deleter拥有全局 owner/administrator则禁止移除应用 ownerisAppOwnerRemoval检查被删用户是否为应用 owner但可移除其他成员若删除者是应用成员则USER/ADMINISTRATOR应用角色不能移除他人OWNER应用角色不能移除自己isSelfRemoval检查——只有应用 owner 可以移除普通成员而任何人都不能把应用 owner 从应用 owner位置上直接抹掉。App Administrator能管 Face Services不能管应用应用 administrator全局 user 角色 应用 administrator 角色可以创建和管理 Face Services但不能管理应用本身及其应用用户。对应源码中verifyWritePrivilegesToApp(user, app, adminDenied)提供了管理员也拒绝的模式当adminDenied为 true 且用户应用角色为AppRole.ADMINISTRATOR时抛出InsufficientPrivilegesException用于保护应用级管理操作如应用自身的增删改而普通的模型、Face Service 级写操作只排除AppRole.USER。App User最低权限但足够集成应用 user 是权限最低的角色组合全局 user 应用 user在应用内不能做任何管理操作。但由于应用 user 已经能够获取集成所需的全部信息如应用 API 密钥、Face Service 调用能力等官方推荐大多数 CompreFace 用户采用这一角色。授权核心逻辑速览AuthorizationManager所有权限判定集中在 AuthorizationManager.java 中几个关键方法与文档规则的对应关系如下方法对应文档规则verifyGlobalWritePrivileges(user)只有全局OWNER/ADMINISTRATOR可执行系统级写操作否则抛InsufficientPrivilegesExceptionverifyReadPrivilegesToApp(user, app)全局USER必须已加入该应用存在应用角色才能读取owner/administrator 直接放行verifyWritePrivilegesToApp(user, app[, adminDenied])全局 owner/administrator 放行应用内USER一律拒绝写操作adminDenied场景下应用ADMINISTRATOR也被拒绝保护应用级管理操作verifyUserDeletionFromApp(deleter, userGuid, app)编码应用 owner 不能被全局管理员直接移除、不能自删、非 owner 成员不能删人三条限制verifyCanDeleteUser(userDeleteDto)编码全局 owner 不可删除、全局 user 只能删自己两条限制异常方面越权统一抛出 InsufficientPrivilegesException.java由全局异常处理器映射为 HTTP 响应。测试用例 AuthorizationManagerTest.java 对上述各分支全局 user 读应用、admin 被拒绝的场景、owner 自删/互删等提供了行为级验证。实践建议与源码行为一致的操作路径结合文档建议与上述实现实际运营 CompreFace 时的操作要点保留全局 owner 的唯一性首位注册用户即为 owner且任何流程都无法删除 owner。若要更换 owner先由 owner 将全局 owner 相关管理权交接getGlobalRolesToAssign允许 owner 分配全部角色再走删除/移交流程最小化 administrator全局 administrator 与 owner 几乎等权仅多一条不能管理 owner的限制建议只授予必要运维人员应用成员权限分级项目经理/团队负责人 → 应用 owner 或 administrator普通集成开发者 → 应用 user默认推荐运维人员无需加入应用全局 owner/administrator 对任何应用都拥有全部读写权限verifyWritePrivilegesToApp开头即放行将其加入应用纯属冗余删除成员前先确认角色应用 owner 不可被直接移出应用需先转让 owner全局 user 只能删除自己。以上规则均有源码依据可在 AuthorizationManager.java、UserService.java、AppService.java 及对应测试类中逐条核对作为多团队共用一套 CompreFace 实例时的权限设计参考。赞分享人工智能计算机视觉后端AI 应用【免费下载链接】CompreFaceLeading free and open-source face recognition system项目地址https://gitcode.com/gh_mirrors/co/CompreFace点击查看免费下载相关推荐ToolJet 用户角色User Roles详解RBAC 权限模型与工作区角色管理实战ToolJet 用户角色User Roles详解RBAC 权限模型与工作区角色管理实战 导读 本文围绕 ToolJet 开源低代码平台的 用户角色Use低代码后端前端AI 应用MCP 服务StarRocks SHOW ROLES 实战详解查看系统全部角色与权限审计StarRocks SHOW ROLES 实战详解查看系统全部角色与权限审计 SHOW ROLES 是 StarRocks 中用于查看当前系统全部角色的 SQ数据库OLAP数据仓库大数据湖仓一体数据分析OpenProject 角色与权限Roles and Permissions系统管理完整指南OpenProject 角色与权限Roles and Permissions系统管理完整指南 本文是 OpenProject 系统管理指南的「用户与权限」系后端前端项目管理企业应用协同办公上一篇Masuit.Tools表达式树构建动态Lambda表达式生成的终极指南下一篇ControlRoom 终极错误排查指南10个常见问题与快速解决方案 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考