Wagtail 1.8 (LTS) 版本全解析：页面隐私权限、批量删除管控与 Elasticsearch 5 支持

Wagtail 1.8 (LTS) 版本全解析页面隐私权限、批量删除管控与 Elasticsearch 5 支持【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail本篇技术文章以 Wagtail 1.82016 年 12 月 15 日发布的长期支持版本的官方发布说明docs/releases/1.8.rst为核心骨架系统梳理该版本引入的页面隐私选项、页面批量删除权限管控、Elasticsearch 5 支持、权限受限的 admin 面包屑导航等关键特性并结合当前仓库源码逐项印证底层实现。读者读完本文后将能理解 Wagtail 1.8 中隐私限制的完整类型与配置方式、bulk_delete权限的判定逻辑、OPTIONS配置迁移方法以及从 1.7 升级到 1.8 时自定义图片 Rendition 模型必须执行的unique_together调整。一、版本定位首个页面权限相关的 LTS 版本Wagtail 1.8 被官方指定为 Long Term SupportLTS版本。根据 docs/releases/1.8.rst 的说明LTS 版本会持续接收必要的维护更新用于解决安全与数据丢失相关问题直到下一个 LTS 版本发布通常相隔约 8 个月。这意味着 1.8 系列适合作为生产环境的长期基线版本值得重点关注其安全相关的权限与数据保护能力。该版本的发布团队覆盖了多位核心贡献者页面隐私选项由 Shawn Makinson、Tom Miller、Luca Perico 与 Matt Westcott 开发批量删除权限管控与 Elasticsearch 5 支持分别由 Matt Westcott 与 Karl Hobley 完成权限受限的 admin 面包屑导航由 Jeffrey Chau、Robert Rollins 和 Matt Westcott 合作实现。二、新页面隐私选项从共享密码走向细粒度访问控制2.1 特性概述在 Wagtail 1.8 之前页面访问限制只能通过共享密码实现。1.8 引入了基于用户账户与用户组成员身份的访问限制使管理员无需编写任何额外代码即可在后台搭建内网式intranet-style站点。如图 1 所示页面的 Privacy 控件提供四种可见性选项。2.2 四种隐私限制类型与源码映射从当前仓库源码 wagtail/models/view_restrictions.py 可以看到BaseViewRestriction定义了完整的限制类型常量与选项NONE none PASSWORD password GROUPS groups LOGIN login RESTRICTION_CHOICES ( (NONE, _(Public)), (PASSWORD, _(Private, accessible with a shared password)), (LOGIN, _(Private, accessible to any logged-in users)), (GROUPS, _(Private, accessible to users in specific groups)), )四种类型的实际含义如下限制类型常量访问条件公开BaseViewRestriction.NONE无需任何限制登录用户可访问BaseViewRestriction.LOGIN任何已登录账户均可访问与权限级别无关共享密码BaseViewRestriction.PASSWORD输入指定共享密码即可与站点用户账户体系无关指定用户组BaseViewRestriction.GROUPS必须登录且属于指定的一个或多个用户组页面模型侧的映射位于 wagtail/models/pages.pyPageViewRestriction(BaseViewRestriction)通过page models.ForeignKey(...)关联页面restriction_type与password字段分别存储限制类型与共享密码groups为多对多关联的用户组集合。一个页面连同其子页面可同时存在多条限制记录Wagtail 会依次校验。2.3 访问判定逻辑BaseViewRestriction.accept_request(request)见 wagtail/models/view_restrictions.py负责判定当前请求是否通过限制对于PASSWORD类型Wagtail 通过passed_view_restrictions_session_key会话键记录已通过密码校验的页面避免重复要求输入LOGIN与GROUPS类型则基于登录态与用户组成员关系判定。此外删除或修改隐私限制时会通过delete()与save()中的自定义逻辑写入wagtail.view_restriction.*审计日志wagtail/models/pages.py方便追溯权限变更历史。2.4 实践要点拥有页面 publish 权限的用户即可在页面编辑界面的右上角点击 Privacy 控件设置隐私限制会作用于该页面及其所有子页面界面中有明确警告提示。共享密码以明文形式存储于数据库官方文档 docs/advanced_topics/privacy.md 明确警告共享密码不应用于保护敏感内容推荐尽可能要求用户登录访问。若站点不需要密码分享场景可通过WAGTAIL_PRIVATE_PAGE_OPTIONS {SHARED_PASSWORD: False}在后台隐藏共享密码选项已有密码限制仍会生效但不再于后台可见可通过 Django shell 清理from wagtail.models import Page for page in Page.objects.private(): page.get_view_restrictions().filter(restriction_typepassword).delete()前端登录页可通过WAGTAIL_FRONTEND_LOGIN_TEMPLATE指定自定义模板通过WAGTAIL_FRONTEND_LOGIN_URL接入既有登录视图页面模型也可重写get_default_privacy_setting为该页面类型设置默认隐私限制例如默认要求登录或自动生成随机共享密码详见 docs/advanced_topics/privacy.md。三、批量删除页面的权限管控3.1 背景与设计动机此前任何对页面及其后代页面拥有编辑权限的用户都可以将整个子树作为一次操作删除存在误删风险。Wagtail 1.8 修订了权限规则仅拥有基础权限的用户只能删除没有子页面的叶子页面要删除整个子树必须先逐个删除每个子页面新增bulk_delete权限类型允许用户像以前一样删除带子页面的页面超级用户隐式拥有该权限行为不变。3.2 权限类型定义与判定实现权限类型的声明位于 wagtail/models/pages.py(bulk_delete, _(Bulk delete), _(Delete pages with children)),对应中文含义为批量删除——删除带子页面的页面。该权限通过 Settings - Groups 区域进行分配默认没有任何用户组被授予该权限。核心判定逻辑在PagePermissionTester.can_delete()wagtail/models/pages.pydef can_delete(self, ignore_bulkFalse): if not self.user.is_active: return False if self.page_is_root: # root node is not a page and can never be deleted, even by superusers return False if self.user.is_superuser: # superusers require no further checks return True # if the user does not have bulk_delete permission, they may only delete leaf pages if ( bulk_delete not in self.permissions and not self.page.is_leaf() and not ignore_bulk ): return False ...关键点解读根节点root永远不可删除即使是超级用户超级用户直接放行无需任何检查非超级用户若缺少bulk_delete权限且目标页面非叶子节点则删除被拒绝——这就是必须先逐个删除子页面的底层保证代码中的ignore_bulk参数被管理后台的树形批量删除视图使用见 wagtail/admin/views/pages/bulk_actions/delete.py其check_perm直接调用can_delete()用于回收站/批量删除场景的兼容。此外can_delete后续还会校验发布状态与页面归属无 publish 权限的用户不能删除包含已发布live页面的子树仅拥有 add 权限的用户只能删除全部为自己所有且非 live 的页面。这些逻辑共同构成 1.8 之后页面删除的完整安全网。3.3 通过数据迁移恢复旧行为由于默认没有任何组被授予bulk_delete权限希望恢复旧行为的管理员无需在后台手工逐组配置可直接使用数据迁移。官方发布说明给出的完整示例为./manage.py makemigrations myapp --empty --name assign_bulk_delete_permission将myapp替换为项目实际应用名后编辑生成的迁移文件from __future__ import unicode_literals from django.db import migrations def add_bulk_delete_permission(apps, schema_editor): Find all groups with add/edit page permissions, and assign them bulk_delete permission GroupPagePermission apps.get_model(wagtailcore, GroupPagePermission) for group_id, page_id in GroupPagePermission.objects.filter( permission_type__in[add, edit] ).values_list(group, page).distinct(): GroupPagePermission.objects.create( group_idgroup_id, page_idpage_id, permission_typebulk_delete ) def remove_bulk_delete_permission(apps, schema_editor): GroupPagePermission apps.get_model(wagtailcore, GroupPagePermission) GroupPagePermission.objects.filter(permission_typebulk_delete).delete() class Migration(migrations.Migration): dependencies [ # keep the original dependencies line ] operations [ migrations.RunPython(add_bulk_delete_permission, remove_bulk_delete_permission), ]该迁移为所有拥有 add/edit 页面权限的用户组补齐bulk_delete从而精确复刻升级前的删除行为remove_bulk_delete_permission作为反向操作便于回滚。四、Elasticsearch 5 支持与OPTIONS配置迁移4.1 后端能力扩展Wagtail 1.8 正式支持 Elasticsearch 5并允许覆盖默认的索引设置。同时Wagtail 官方对 Elasticsearch 构造器的额外参数收纳方式做了规范化WAGTAILSEARCH_BACKENDS中所有直接传入 Elasticsearch 构造器的额外键都应移入新增的OPTIONS字典旧行为仍受支持但已标记为弃用。4.2 配置示例对比旧写法1.8 之前from elasticsearch import RequestsHttpConnection WAGTAILSEARCH_BACKENDS { default: { BACKEND: wagtail.wagtailsearch.backends.elasticsearch, connection_class: RequestsHttpConnection, } }新写法1.8 起推荐from elasticsearch import RequestsHttpConnection WAGTAILSEARCH_BACKENDS { default: { BACKEND: wagtail.wagtailsearch.backends.elasticsearch, OPTIONS: { connection_class: RequestsHttpConnection, } } }迁移完成后所有需要透传给 Elasticsearch 客户端构造器的参数如connection_class、超时、重试策略等统一放置在OPTIONS内。需要注意的是1.8 时代的后端路径为wagtail.wagtailsearch.backends.elasticsearch在当前的仓库中Elasticsearch 后端已演进为按主版本拆分的模块wagtail/search/backends 下的elasticsearch7.py、elasticsearch8.py、elasticsearch9.py以及 OpenSearch 后端opensearch2.py、opensearch3.py配置时请以你所安装的 Wagtail 版本对应的文档为准。五、权限受限的 admin 面包屑导航与多租户铺垫Wagtail 1.8 中admin 内的面包屑breadcrumb链接被限制为覆盖用户拥有权限的全部页面的那部分页面树。这与 Wagtail 1.6 引入的 explorer 侧边栏菜单改动一脉相承均为后续完整多租户支持同一 Wagtail 安装上通过权限配置完全隔离多个站点铺路。从源码角度看这一改动与页面树权限查询紧密相关PagePermissionTester初始化时即通过self.page.path.startswith(perm.page.path)wagtail/models/pages.py过滤出用户可见的权限路径集合admin 前端据此只渲染有权限的树片段从而避免用户看到无权访问的页面分支。六、其他值得关注的新特性发布说明还列出了以下实用功能多数在当前仓库中仍有对应实现Page.get_admin_display_title()可在页面模型中重写自定义后台展示的标题默认返回draft_title实现见 wagtail/models/pages.pyPageQuerySet.first_common_ancestor与in_site前者计算一组页面的最近公共祖先后者将查询集过滤到指定站点内页面选择器会默认打开到覆盖所有所需类型页面的最深祖先节点PageChooserBlock新增target_model选项用于指定必须选择的页面类型当前版本中该参数已映射为新的page_type参数wagtail/blocks/field_block.py新增 StreamField 块类型StaticBlock用于在 stream 中占位但无任何配置的块定义于 wagtail/blocks/static_block.py后台文案默认为此块没有选项新增BlockQuoteBlock基于TextBlock实现渲染为blockquote引用块wagtail/blocks/field_block.pyChoiceBlock接受可调用对象作为 choices 列表ModelAdmin新增exclude_from_explorer从 explorer 视图中隐藏指定页面类型AbstractForm新增get_landing_page_templategetter并尊重页面模型自定义的get_template登录页模板新增above_login、below_login、fields、login_form自定义区块锁定页面在浏览器层面禁用编辑防止误操作Cloudflare 前端缓存模块升级到 v4 API见下文升级说明。七、Bug 修复盘点1.8 同时修复了一批影响面较广的问题包括set_url_paths管理命令兼容 Django 1.10表单构建器邮件通知正确输出多值字段仅拥有 publish 权限的用户不再被隐式授予删除页面权限与本文第三节的权限收紧直接相关未安装 wagtailsearchpromotions 时search_garbage_collect命令正常工作wagtail.contrib.settings上下文处理器在request.site不可用时不再报错TableBlock内容现在会被索引用于搜索Page.copy()标记为alters_data防止模板代码意外触发复制。八、升级注意事项1.7 → 1.88.1 自定义图片 Rendition 模型的unique_together必须更新如果项目使用了自定义图片模型升级后必须修改对应 Rendition 模型的唯一性约束——将filter字段改为filter_spec# 升级前 unique_together ( (image, filter, focal_point_key), ) # 升级后 unique_together ( (image, filter_spec, focal_point_key), )然后照常执行迁移./manage.py makemigrations ./manage.py migrate该改动在当前仓库源码中得到了印证AbstractRendition现已使用filter_spec models.CharField(max_length255, db_indexTrue)作为筛选器规格字段wagtail/images/models.py存储fill-100x100这类筛选规格字符串。同时第三方代码若直接操作 Filter 与 Rendition 模型需要注意Filter从 Wagtail 1.9 起将不再是 Django 模型对其执行的 ORM 操作如save()、Filter.objects已弃用应改为内存对象实例化flt, created Filter.objects.get_or_create(specfill-100x100)应改写为flt Filter(specfill-100x100)Rendition 模型的filter字段不再使用查询应改在filter_spec字段上进行。8.2get_image_model导入路径变更get_image_model函数应从wagtail.wagtailimages导入而不再从wagtail.wagtailimages.models导入。凡是引用自定义图片模型的地方如自定义图片字段、信号处理都需要同步更新 import 语句。8.3 非管理员删除带子页面的页面需要bulk_delete权限即本文第三节所述默认无任何组被授予该权限可通过上述数据迁移恢复旧行为。管理员superuser隐式拥有该权限行为不变。8.4 Cloudflare 缓存后端要求新增ZONEID配置wagtail.contrib.wagtailfrontendcache.backends.CloudflareBackend从 v1 API 迁移至 v4 APIv1 已于 2016 年 11 月 9 日停止支持新 API 需要 zone identifier。配置示例如下WAGTAILFRONTENDCACHE { cloudflare: { BACKEND: wagtail.contrib.wagtailfrontendcache.backends.CloudflareBackend, EMAIL: your-cloudflare-email-addressexample.com, TOKEN: your cloudflare api token, ZONEID: your cloudflare domain zone id, }, }当前仓库中该后端的实现位于 wagtail/contrib/frontend_cache/backends/cloudflare.py其构造函数通过params.pop(ZONEID)强制读取 zone id并拼装 v4 purge 端点https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache同时兼容EMAIL TOKENAPI Key与BEARER_TOKEN两种认证方式。对应测试见 wagtail/contrib/frontend_cache/tests.py其中以ZONEID: this is a zone id验证了配置解析。升级时请务必在WAGTAILFRONTENDCACHE中补齐ZONEID否则后端将因缺少该键而抛出KeyError。8.5 Elasticsearch 构造器参数迁入OPTIONS见本文第四节WAGTAILSEARCH_BACKENDS中所有额外键都应移入新的OPTIONS字典旧行为仍可用但已弃用建议在升级窗口内一并完成迁移。九、总结与升级建议Wagtail 1.8 作为 LTS 版本其核心价值集中在数据安全与权限细粒度化页面隐私从单一密码扩展为登录/用户组/密码三种模式页面删除通过bulk_delete权限收紧了整树误删风险admin 导航逐步向权限隔离演进。升级到 1.8 时请重点核对四项变更自定义 Rendition 模型的unique_together、get_image_model导入路径、非管理员用户的bulk_delete权限分配可用数据迁移一键恢复、Cloudflare 后端的ZONEID与 Elasticsearch 的OPTIONS配置。完成这些调整后即可平稳享受 LTS 版本带来的长期维护保障。【免费下载链接】wagtailA Django content management system focused on flexibility and user experience项目地址: https://gitcode.com/GitHub_Trending/wa/wagtail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考