权限模型

CmsKit 的权限集中在 FreeKit.CmsKit.Contracts.CmsKitPermissions（分组常量，根分组名为 CmsKit）。本文讲的是「权限如何挂在子域与内容上、与 Identity 权限是什么关系」——它是一份模型说明，不是端点清单（端点清单见 Swagger）。

旧文档中出现的 AddFreeKitCmsKit() 与 [Authorize(Policy = CmsKitPermissions.Articles.Create)] 写法在源码中不存在：真实授权特性是 KitAuthorize，权限常量也以下表为准。

权限与子域的对应

上图说明：CmsKit 只定义权限常量并在 CmsKitSettingDefinitionProvider 中登记；真正的「谁能有什么权限」由 Identity 模块以 Claim 形式分配到角色/用户。管理端走 KitAuthorize 显式校验，用户端走 ICurrentUser 归属校验。

权限以 CmsKit. 为前缀，按子域分组——每个分组对应一个业务能力域，谁负责哪个域的「管理动作」一目了然：

分组	代表常量	运行时权限字符串（前缀 CmsKit.）
Articles	Default / GetList / Get / Create / Update / Delete / Audit / SetRecommend / ExtractSeo	CmsKit.Articles.*
ShortMsgs	Default / GetList / Audit / Delete / ExtractTopic	CmsKit.ShortMsgs.*
Comments	Default / GetList / Delete / Audit / Update / CorrectCount	CmsKit.Comments.*
Channels	Default / GetList / Create / Update / Delete / Manage	CmsKit.Channels.*
Classifies	Default / GetList / Create / Update / Delete / Manage	CmsKit.Classifies.*
Tags	Default / GetList / Create / Update / Delete / CorrectArticleCount / Manage	CmsKit.Tags.*
Topics	Default / GetList / Create / Update / Delete / Manage	CmsKit.Topics.*
Clubs	Default / GetList / Create / Update / Delete / Manage	CmsKit.Clubs.*
Polls	Default / GetList / Delete / Manage	CmsKit.Polls.*
UserReports	Default / GetList / Handle	CmsKit.UserReports.*
Users	Default / GetList / Manage	CmsKit.Users.*
UserInteractionLogs	Default / GetList / GetAll	CmsKit.UserInteractionLogs.*
Notifications	Default / GetList / Manage	CmsKit.Notifications.*
AuditLog	Default / Audit	CmsKit.AuditLog.*
Statistics	Default / GetTrendChart	CmsKit.Statistics.*

* 表示「同分组所有权限」。例如 CmsKit.Tags.Manage 通常授予标签管理的完整能力。

两类授权边界

CmsKit 在「谁能做什么」上分两层，这是理解整个权限模型的关键：

1. 管理端：显式权限（KitAuthorize） 管理端接口（如 /api/cms/admin/...）在方法上用 KitAuthorize 声明所需权限，第一个参数是编译期可校验的权限常量，第二个是面向管理员的功能说明：

   [HttpDelete("{id}")]
   [KitAuthorize(CmsKitPermissions.Tags.Delete, "标签管理")]
   public async Task DeleteAsync(Guid id) => await tagService.DeleteAsync(id);

2. 用户端：所有权校验（ICurrentUser） 用户端写操作（删除自己的文章、取消自己的通知等）不依赖上述权限常量，而是在 IArticleService / INotificationService 等服务内基于 ICurrentUser 做所有权校验，非法时抛业务异常。

为什么要这样分：管理动作是「运营能否操作他人内容」，必须显式授权；用户动作是「你能否动你自己的东西」，用归属校验更自然，也更细——不会出现「有 Articles.Update 就能改别人文章」的越权。

与 Identity 权限的关系

• CmsKit 只定义「有哪些权限」（常量 + 在 CmsKitSettingDefinitionProvider 中登记），不负责分配 UI。
• 权限以 Claim 形式挂到角色/用户，由 Identity 模块统一管理（分配、角色菜单等见 Identity 权限模型）。
• 因此「谁能进 CmsKit 管理后台」是 Identity 的配置问题，不是 CmsKit 自身的能力。

相关文档

• CmsKit 总览
• Identity 权限模型
• 文章与内容
• 治理：审核/举报