本文介绍了Wagtail过滤器page-childs-elements基于已登录用户的权限的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用Wagtail在一个小型站点上工作.这个站点都是关于主页"和几个子页面"的.到目前为止,这非常简单!但是,根据用户(不是管理员)所在的组,应该显示正确的子页面!

I am working on a small site using Wagtail. This site is all about a "mainpage" and several "subpages". So far it is pretty simple! But, depending on what group the user (not admin) is in, the right subpages should show up!

请参阅以下设置(最小化),以了解我在说什么.

See the following setup (minimized), to get an idea of what I am talking about.

如果我对ToolKitPart设置了权限(例如要求显式的用户登录和组成员身份),则会发生以下情况:

If I set permissions on ToolKitPart (like requiring explicit user-login and group-membership), then the following is happening:

  • 使用完全限定的路径转到页面时,要求用户登录,并且在权限不足的情况下,用户将看不到内容!

  • when going to the page using the fully qualified path, the user is requested to login and, in the case of insufficient rights, the user will not see the content!

当进入ToolkitIndex-Page时,将显示所有子级,包括用户永远不应该看到的子级,而无需登录或成为某个组的成员.

when going to the ToolkitIndex-Page, all children are displayed, including the ones the user never should see, without the need to be logged in or being a member of a certain group.

class ToolkitIndex(Page):
    def get_context(self, request):
        # Update context to include only published posts, ordered by reverse-chron
        context = super().get_context(request)
        blogpages = self.get_children().live().order_by('-first_published_at')
        context['pages'] = blogpages    
        return context

class ToolkitPart(Page):
    body = StreamField([
        ('staff', MpStaff()),
        ('news', MpNews()),
        ('stuff', MpStuff()),
        ('teditor', blocks.RichTextBlock()),
        ('reditor', blocks.RawHTMLBlock()),
    ], blank=True)

    content_panels = Page.content_panels + [
        StreamFieldPanel('body'),
    ]

class MpNews(blocks.StructBlock):
    head = blocks.TextBlock(required=True, help_text='Schlagzeile')
    lead = blocks.TextBlock(required=False, help_text='Einleitung')
    body = blocks.RichTextBlock(required=True, help_text='Inhalt')
    image = ImageChooserBlock(required=False)

    type = blocks.ChoiceBlock(
        choices=[('default', 'Standard'),
             ('highlight', 'Hervorgehoben'),
             ], required=True)

    class Meta:
        template = 'home/mparts/toolkit_news.html'
        icon = 'code'

有什么办法解决这个问题吗?

Any idea how to solve this?

推荐答案

假定您已使用Wagtail的私有页面功能,它们存储在 PageViewRestriction 模型.不幸的是,Wagtail当前不提供对当前页面请求以外的任何内容应用这些权限检查的方法,因此您必须自己重新创建此逻辑才能将查询集过滤到用户的查看权限.这将是(未试用的):

Assuming you've set these permissions up using Wagtail's private pages feature, these are stored in the PageViewRestriction model. Unfortunately Wagtail doesn't currently provide a way to apply these permission checks against anything other than the current page request, so you'd have to recreate this logic yourself to filter a queryset to the user's view permissions. This would be something like (untested):

from django.db.models import Q

class ToolkitIndex(Page):
    def get_context(self, request):
        context = super().get_context(request)
        blogpages = self.get_children().live().order_by('-first_published_at')

        if not request.user.is_authenticated:
            blogpages = blogpages.public()  # only pages with no view restrictions at all

        else:
            blogpages = blogpages.filter(
                # pages with no view restrictions
                Q(view_restrictions__isnull=True)
                # pages restricted to any logged-in user
                | Q(view_restrictions__restriction_type='login')
                # pages restricted by group
                | Q(view_restrictions__restriction_type='groups', view_restrictions__groups__in=request.user.groups.all())
            )

免责声明:

  • 这不考虑受共享密码保护的页面
  • 要完全正确,我们需要考虑视图限制沿树传播的事实(因此,即使子页面没有直接附加的视图限制记录,子页面仍可能受到限制);但是,我们只查看当前页面的直接子级(显然,他们可以访问...),因此这里不会出现此问题.
  • PageViewRestriction 不是公共的Wagtail API,并且在将来的版本中可能会更改-特别是,请参见 RFC 32 ,该更改可能会在不久的将来发生.
  • This doesn't account for pages that are protected by a shared password
  • To be fully correct, we'd need to account for the fact that view restrictions propagate down the tree (and so a subpage may still be restricted even if it doesn't have a view restriction record directly attached to it); however, we're only looking at immediate children of the current page (which they evidently do have access to...) so that issue doesn't come up here.
  • PageViewRestriction is not a public Wagtail API and may change in future releases - in particular, see RFC 32 for a proposed change that may happen in the fairly near future.

这篇关于Wagtail过滤器page-childs-elements基于已登录用户的权限的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

11-03 12:56