CjrfViewMiddleware от Django не работает в сочетании с ответом, генерируемым промежуточным ПО - PullRequest
1 голос
/ 20 марта 2012

Мое приложение Django использует стек промежуточного программного обеспечения, содержащий CsrfViewMiddleware и собственное промежуточное программное обеспечение:

MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'myapp.OwnMiddleware'
)

Основная идея состоит в том, что если URL-адрес не может быть найден, то есть не найдена функция просмотра,эта ошибка перехватывается OwnMiddleware.process_response(), которая возвращает собственный ответ, если HTTP-статус 404 (и некоторые другие условия выполняются).

Это работает нормально, с одной проблемой: потому что не вызывается функция представлениякогда предоставляется недопустимый URL-адрес (в соответствии с URLconf), CsrfViewMiddleware.process_view() никогда не вызывается, и, таким образом, файл CSRF-cookie не создается.

Поэтому вся система CSRF не работает, а маркер CSRF по-прежнему имеет значение "NOTPROVIDED "в OwnMiddleware.process_response (что означает, что {% csrf_token%} генерирует пустую строку вместо обычного скрытого поля формы).

Каков наилучший способ решения этой проблемы, т.е. OwnMiddleware перехватывает 404s ивернуть еще один (не 404) ответ, при этом все еще имея возможность использовать токен CSRF в этих ответах?

Заранее спасибо.

1 Ответ

2 голосов
/ 20 марта 2012

Вы можете вручную запустить что-то вроде:

CsrfViewMiddleware.process_view(request, lambda: your_response, [], {})

PS Я думаю, что лучше использовать handler404 , чтобы поймать 404 х

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...