在 req.path 中使用 django 的 reverse 函数

Question

我偶然发现了邀请功能以了解它的工作原理。我在http://www.pythondiary.com/tutorials/create-invite-only-website.html 上找到了这篇博文。作者在那里说（它检查路径，因为如果不检查这将导致无限循环）。如何使用反向功能检查路径？

class Invite(models.Model):
    INVITE_CHOICES = (
    ('G', 'General'),
    ('I', 'Invitational'),
    )
    user = models.OneToOneField(User)
    cookie = models.UUIDField(default=uuid.uuid4)
    token = models.UUIDField(default=uuid.uuid4, unique=True, editable=False)

    def __str__(self):
        return self.user.username

    # def get_absolute_url(self):
    #     return reverse('user_mgmt:confirm_invite', kwargs={'token': self.token})

class InvitedMiddleware(object):
    def process_request(self, req):
        if req.path == '/i.auth': # what path is this?
            return None
        if not req.user.is_authenticated():
            if 'token' in req.COOKIES:
                return redirect('user_mgmt.views.login_user')
        return None

    def process_response(self, req, resp):
        if req.user.is_authenticated():
            if req.user.is_staff:
                return resp
            if 'token' in req.COOKIES:
                token = req.COOKIES['token']
            else:
                invite = Invite.objects.get(user=req.user)
                token = invite.token
            resp.set_cookie('token', token, MAX_AGE=1209600)
        return resp

Answer 1

好的。但首先请注意，此示例使用旧的 Middleware 声明和语法。当您感到舒适时，切换到新的Middleware 语法。此外，它是 5 年前编写的（！），从那时起 Django 发生了很多变化！

从docs召回：

你可以把它（中间件）想象成洋葱：每个中间件类都是一个“层” 包裹视图，它位于洋葱的核心。如果请求 穿过洋葱的所有层 [...]，一直到 核心的视图，然后响应将通过每一层 （以相反的顺序）在回来的路上。

所以，作者在这里做的是这样的：

根据InvitedMiddleware 在MIDDLEWARE 设置中出现的顺序，InvitedMiddleware 将在每个view 调用之前被调用。它检查request.path（即即将调用view，即将渲染模板的url）是否为'/i.auth'（即127.0.0.1:8000/i.auth/。如果是，那么他返回@ 987654335@（视图从未被调用）。现在，他这样做了，这是未知的。他说我们稍后会了解这条路径的作用，但他从来没有这样做过（！）。也许有本教程的第二个系列，谁知道呢？

无论如何，如果请求的路径不是'/i.auth'，则执行另一次检查。如果用户未通过身份验证。但我认为从这里开始非常简单。请记住，所有这些都发生在视图被调用之前。

如果，现在您使用了reverse 方法，它应该如下所示：

if req.path == reverse('url_name', ...):

其中... 是任何潜在的位置args 或/和kwargs。

但该帖子的作者并未在某处定义此 URL。他也没有解释它的结构。我认为通过它并继续其余部分是安全的。