Wagtail 权限体系解析页面、媒体资源与集合的分级授权机制【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtailWagtail 在 Django 原生权限系统之上针对内容协作场景扩展出一套“按页面树/集合树向下传播”的权限模型。本文以官方文档 docs/topics/permissions.md 为主体完整覆盖页面权限、图片/文档权限、集合管理权限、自定义权限以及编辑器字段级权限五个部分并结合 wagtail/permission_policies 下的策略类源码讲清每个权限类型在代码层面是如何判定的帮助你在多人协作站点中正确配置 Wagtail 后台的权限。概述Wagtail 如何扩展 Django 权限系统Wagtail 适配并扩展了 Django 的权限系统以满足网站内容创作中的典型需求审核工作流moderation workflows以及多个团队分别负责站点不同区域或多个站点共存于同一个 Wagtail 安装实例的协作模式。权限可以在 Wagtail 后台的Settings → Groups设置 → 组区域中配置。文档同时提醒尽管 Wagtail 支持多种用户角色与权限组合后台管理界面仍应限制为可信用户访问。对于权限在 Wagtail 内部的实现机制permission policy、策略注册表等官方另有专门的参考文档 权限参考本文会在各节结合源码对其做必要补充。页面权限沿页面树向下传播传播规则与一个直观例子页面权限可以挂在页面树的任意节点上并沿树向下传播。官方文档给出的例子是MegaCorp/ About us Offices/ UK France Germany如果某个组对Offices页面拥有 edit 权限那么该组自动获得编辑UK、France、Germany页面的能力。若要对整棵树全局生效可以把权限授予root页面——因为所有页面都必须位于 root 节点之下且 root 不可删除这样就能覆盖现在和将来创建的所有页面。这一“向下传播”的语义在源码中有明确体现。wagtail/permission_policies/pages.py 中PagePermissionPolicy的类注释写明权限可通过GroupPagePermission模型定义在树的任意节点上并向子树传播。实例级的判定逻辑在 user_has_any_permission_for_instance 中def user_has_any_permission_for_instance(self, user, actions, instance): ... for perm in self.get_cached_permissions_for_user(user): if instance.pk perm.page_id or instance.is_descendant_of(perm.page): permissions.add(perm.permission.codename)即只要目标页面是权限授予节点的自身或其后代is_descendant_of该权限记录就计入判定。所有权ownership规则创建者天然可编辑每当用户通过 Wagtail 后台创建页面时该用户即被指定为页面的 owner。任何拥有 add 权限的用户都可以编辑自己拥有的页面以及添加新页面。文档解释了这条规则的现实动机建页通常是迭代过程会经过多个草稿版本如果只允许创建草稿却不允许后续编辑这种权限就毫无实用价值。这条“add 蕴含对自己所有页面的 change”规则在 pages.py 第 107–111 行 有直接实现if ( perm.permission.codename self._get_permission_codename(add) and instance.owner_id user.pk ): permissions.add(self._get_permission_codename(change))同时要注意与 Django 标准权限模型的一处差异edit 隐含删除能力Wagtail 没有独立的 delete 页面权限。全部页面权限类型文档定义的完整权限集合如下这也是 Groups 编辑表单中出现的选项Add添加——允许在该页面下创建新子页面前提是页面模型允许该类型见页面类型的业务规则并允许编辑和删除当前用户自己拥有的页面。已发布的页面若用户没有 publish 权限则不能被删除。Edit编辑——允许编辑和删除该页面及其所有子孙页面不限所有权。只有 edit 权限的用户不能创建新页面只能编辑已有页面。已发布页面同样需要 publish 权限才能删除。Publish发布——允许发布/取消发布该页面及其子孙页面。没有 publish 权限的用户无法直接做出对前台访客可见的变更只能将修改提交审核。publish 与 edit 相互独立只有 publish 权限的用户自己不能做任何编辑。Bulk delete批量删除——允许在一次操作中删除仍有子孙页面的页面。没有该权限时用户必须先逐个删除子孙页面再删父页面。这是一个防止误删的保护措施。该权限必须与 add/edit 配合使用本身不提供任何删除权只提供“快捷方式”例如仅有 add bulk delete 的用户只能批量删除全部由该用户拥有且未发布的页面。Lock锁定——允许锁定该页面及其子孙页面阻止其他用户继续编辑。Unlock解锁——允许解锁该页面及其子孙页面即使页面是其他用户锁定的。没有该权限时只有锁定的用户本人及超级用户才能解锁。此外文档明确草稿只有在用户拥有 Edit 或 Publish 权限时才可见“Drafts can be viewed only if the user has either Edit or Publish permission.”。在 wagtail/permissions.py 第 98–112 行 可以看到 Wagtail 为Page注册的全局策略实例page_permission_policy PagePermissionPolicy( swapper.get_model_name(wagtailcore, Page) ) ... register_permission_policy(AbstractPage, page_permission_policy)PagePermissionPolicy继承自OwnershipPermissionPolicy见 wagtail/permission_policies/base.py这也是页面权限与 Django 标准 add/change/delete 权限码之间的转换点——策略内部把 Wagtail 的 add/edit/publish 等语义映射到change、add等 Django 权限码上再查询GroupPagePermission记录。图片与文档权限所有权 集合Collection双重控制图片和文档的权限规则与页面类似同样是基于所有权的模型图片和文档视为由上传者拥有拥有 add 权限的用户可以编辑自己拥有的资源删除被视为等同于编辑没有专门的权限类型。集合Collections如何控制访问范围对特定范围的图片/文档可以通过集合来控制访问默认情况下所有图片与文档都属于root集合有相应权限的用户可以在后台Settings → Collections区域创建新集合授予在root上的权限作用于所有集合——例如拥有 root 上图片 edit 权限的用户可以编辑所有图片授予在其他集合上的权限只作用于该集合及其子集合。choose 权限及其边界图片和文档的choose选用权限决定哪些集合在选择器界面中可见——该选择器用于在页面以及 snippet 等其他模型中插入图片或文档链接。通常所有用户都会获得对所有集合的 choose 权限从而在创建页面时可以使用任何已上传的资源但也可以选择限制该权限从而建立只对特定组可见的集合。文档中有一条重要且常被误解的说明原文以 note 强调choose 权限只是一种 UI 层面的引导机制用于帮助用户选择合适的图片/文档并不是用来隐藏敏感资源防止低权限用户得知的稳健手段。编辑者可以绕过选择器界面直接引用任意文档和图片也能访问文档标题、图片渲染变体等元数据。若要防止未授权用户读取文档内容应使用私有集合前提是在服务器层面妥善保护参见文档存储与分发的安全考虑且这一机制不适用于图片。这套集合级判定逻辑实现于 wagtail/permission_policies/collections.py。以CollectionOwnershipPermissionPolicy图片/文档使用的策略基类为例user_has_permission 只认add、choose、change/delete四类动作其余动作仅对活跃超级用户放行instances_user_has_any_permission_for 精确实现了文档描述的规则可见实例 在拥有 change 权限的集合中∪在拥有 add 权限的集合中且 owner 为自己。注意源码注释直接写明# add permission implies change permission, but only if the instance is owned by the user与文档中“add 权限用户可编辑自己拥有的资源”一一对应“delete 等同 change”的文档表述对应源码中if delete in actions: known_actions.add(change)的归并处理第 253–254 行。集合管理权限Collection management permissions除了管理“集合中的资源”Wagtail 还支持管理集合本身的权限可挂在集合树的任意节点上包含三种Add——允许在该集合下创建新集合Edit——允许修改集合名称、改变其在集合树中的位置以及修改该集合内文档的隐私设置Delete——允许删除位于该集合之下添加的集合。注意集合必须先没有子集合、且集合本身为空才能被删除。文档另附一条限制用户不允许移动或删除“被用于授予其集合管理权限”的那个集合本身——即权限所挂靠的节点是不可操作的。这一点在 CollectionManagementPermissionPolicy._descendants_with_perm 中有清晰实现查询结果通过Q(path__startswith...) Q(depth__gt...)只返回被授权集合的严格后代不含授权节点本身。wagtail/permissions.py 第 102 行 可见 Wagtail 对Collection模型注册的正是这一策略collection_permission_policy CollectionManagementPermissionPolicy(Collection) ... register_permission_policy(Collection, collection_permission_policy)添加自定义权限自定义权限的设置方式参见 Django 官方文档的 custom permissions 一节。对 Wagtail 而言有两个要点已注册到 Wagtail 的模型其权限会自动出现在 Wagtail 后台的 Group 编辑表单中其他模型可以用register_permissionshook 显式把权限加入组管理界面hook 的完整文档与示例见 register_permissions。Wagtail 自身就在 wagtail/wagtail_hooks.py 第 102–114 行 使用此 hook 注册了 workflow/task 权限hooks.register(register_permissions) def register_workflow_permissions(): return Permission.objects.filter( content_type__app_labelwagtailcore, codename__in[add_workflow, change_workflow, delete_workflow], )hook 的通用写法返回一个PermissionQuerySetfrom django.contrib.auth.models import Permission from wagtail import hooks hooks.register(register_permissions) def register_permissions(): app blog model extramodelset return Permission.objects.filter( content_type__app_labelapp, codename__in[ fview_{model}, fadd_{model}, fchange_{model}, fdelete_{model}, ], )与模型无关的自定义权限借助wagtail.admin.models.Admin如果希望添加一个不关联特定模型的自定义权限用于 Wagtail 后台可以以wagtail.admin.models.Admin模型的 content type 来创建该模型定义见 wagtail/admin/models.py 第 16 行。文档给出的示例from django.contrib.auth.models import Permission from django.contrib.contenttypes.models import ContentType from wagtail.admin.models import Admin content_type ContentType.objects.get_for_model(Admin) permission Permission.objects.create( content_typecontent_type, codenamecan_do_something, nameCan do something, )将该权限通过register_permissionshook 注册后它就会显示在 Wagtail 后台 Group 编辑表单的Other permissions分区中与 Can access Wagtail admin 权限并列。FieldPanel 与 PanelGroup 的字段级权限权限还可以用于限制编辑器界面内字段的访问FieldPanel.permission按权限码控制单个面板对用户的可见性。若登录用户不具备该权限该字段面板会从表单中省略。详见 FieldPanel 参考。PanelGroup.permissionPanelGroup的各子类TabbedInterface、ObjectList、FieldRowPanel、MultiFieldPanel都接受permission关键字参数可按权限成组地限制面板。面板体系的自定义用法见 表单面板概述。面板参考文档中的说明是“接受形如myapp.change_blog_category的权限 codename——若登录用户没有该权限该面板将从表单中省略”见 docs/reference/panels.md因此该参数适合用于“同一页面模型对不同角色展示不同字段集”的场景例如只有管理员可见的发布说明字段。小结与延伸阅读Wagtail 的权限体系可以概括为三层页面树层GroupPagePermission沿页面树向下传播add 权限叠加所有权规则edit 隐含 deletepublish 独立控制前台可见性集合层GroupCollectionPermission沿集合树传播图片/文档采用 add/choose/change 三码模型choose 仅是 UI 引导而非安全边界注册表层所有模型通过 wagtail/permissions.py 中的policy_registry/register_permission_policy关联到具体的策略类视图与表单统一向注册表查询判定。如需深入策略类的完整 APIuser_has_permission_for_instance、instances_user_has_any_permission_for等方法签名请阅读 权限参考文档如需在应用中注册自定义策略参考文档建议在对应 app 的wagtail_hooks.py顶部调用register_permission_policy。【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考