1

我有一个视图打算只处理以开头的 POST 请求

user = User.objects.get(username=request.POST['name'])

我是否需要确保视图不是通过 GET 请求调用的？不确定我是在考虑良好的实践/安全类型的事情还是强迫症。

我正在使用@require_POST装饰器，因为使用 GET 调用视图会导致"Key 'name' not found in <QueryDict: {}>500 错误。

我想发生这种情况的唯一机会是，如果用户查看了页面的 HTML，并且出于某种原因考虑尝试action在地址栏中尝试表单的属性——这似乎不太可能。

我自己在几个网站上尝试过这个并得到一个错误页面，而不是一个带有 405 错误的空白页面@require_POST给我。

如果模板设计者错误地创建了指向我的视图的超链接或忘记了，那么防范 GET 请求可能是一种好习惯method="post"？（在这种情况下，我想我应该get_object_or_404在上面使用）

我假设添加@require_GET到仅用于处理 GET 请求的视图是不必要的？

4

2 回答 2

2

似乎您明白为什么要使用@requirePOST. 如果您不想在 上引起错误，另一种选择GET是使用以下内容：

def view(request):
    if request.method == 'POST':
        ..code for post..
    else:
        *redirect, or other code*

至于您是否需要使用@requireGET，唯一可能造成伤害的方法是您需要一个视图来执行GET和POST。即在 上引起操作的表单POST，但只是在 上为用户显示GET。但是，如果您需要GET，那么视图中不应该有任何可能通过POST.

于 2013-01-22T20:57:09.963 回答
1

我是否需要确保视图不是通过 GET 请求调用的？不确定我是在考虑良好的实践/安全类型的事情还是强迫症。

是的。我认为您涉及回答自己的问题。您的视图需要request.POST获取请求错误。如果您想创建无错误代码，您将确保没有获取请求访问此视图。Django 提供了一个方便的、pythonic 的装饰器来做到这一点。我不认为你是强迫症。此外，我不知道在生产中触发错误（通过电子邮件发送给您、记录它等）的代价有多大，但这是需要考虑的事情。

我想发生这种情况的唯一机会是，如果用户查看了页面的 HTML，并且出于某种原因考虑尝试在地址栏中尝试表单的 action 属性——这似乎不太可能。

我认为用户如何对此提出 GET 请求并不重要，我认为只有这个视图必须是一个发布请求才重要。

如果模板设计者错误地创建了指向我的视图的超链接或忘记了 method="post"，那么防范 GET 请求可能是一种好习惯？（在这种情况下，我想我应该使用上面的 get_object_or_404 ）

在这种情况下，我认为考虑可以对此视图提出获取请求的多种方式并不重要。重要的部分是它需要一个 Post 请求。您可以使用可用的工具来确保进入函数的所有请求都是发布请求。

一件事是，name没有假设。你仍然可以得到一个KeyError. 即使您确保请求是 POST，您也无法确保发布请求将具有参数name

这就是为什么get如此频繁地使用

if not request.POST.get('name'):
  # raise some sort of error?
user = User.objects.get(username=request.POST['name'])
于 2013-01-22T23:59:09.390 回答