Пустые ответы от Джанго runserver при проверке прав доступа пользователей

Question

У меня аналогичная проблема для тех, которые перечислены в

Django produces blank pages when POST data is sent and Models are accessed

и

Nginx connection reset, response from uWsgi lost

Вот один из взглядов на вопрос:

@transaction.commit_on_success 
@occ_update 
@checks_status 
def hold(request): 
    if not request.user.has_perm('orders.hold'): 
     return error_response_rollback(NO_PERMISSION_MSG % "hold orders") 
    order = Order.objects.get(pk=request.POST.get('pk')) 
    occ_revision = int(request.POST.get('occ_revision')) 
    agent = Agent.get_agent(request.user) 
    action = Action(agent=agent, type='hold_order', 
        comments=request.POST.get('comments')) 
    action.save() 
    order.hold(action, occ_revision) 
    return ok_response_commit("Order held successfully.") 

error_ response_rollback возвращает транзакцию и возвращает HttpResponse с JSON в качестве ее содержимого.

Я добавляю проверку разрешений ко многим моим представлениям в своем приложении и когда у пользователя нет правильного разрешения, возвращается пустой ответ.

Однако, как и вопросы, упомянутые выше, если вы поставите

print request 

или

request.POST 

заявление ДО проверки прав доступа, строка NO_PERMISSION_MSG JSON возвращается в браузер правильно каждый раз (error_response_rollback возвращает объект HttpResponse с JSON в нем.)

Вы получаете пустые ответы при проверке разрешений перед «печатью req uest ", и у них нет имеют правильные разрешения.

Вы не получите пустые ответы, когда:

1. пользователя имеет необходимые разрешения
2. «запрос на печать» заявление является перед любой проверкой прав доступа
3. вы используете Firefox в любой момент.

Декораторы @occ_update и @checks_status просто перехватывают исключения. Эти проблемы возникают с ними и без них.

Я развиваюсь в Chrome и . Ничего из этого не случилось в Firefox.

Одна страница, которую я нашел, предложил перегрузить объект WSGIRequest, чтобы прочитать запрос до того, как он будет передан в представление, но это кажется мне неприятным, и я предпочел бы найти реальное решение.

Кто-нибудь знает какие-либо исправления/настройки для команды runerver, чтобы помочь решить эту проблему без взлома запроса? Мои пользователи в основном используют Chrome, поэтому я бы предпочел продолжать использовать его ... мы увидим. В настоящее время разрабатывается в Windows с использованием Django 1.3.1

Один из вариантов, который я рассмотрел, - это сделать еще одну команду manage.py, чтобы справиться с этим, но это тоже кажется нехорошим.

Благодаря

---

Update:

я смог реорганизовать свой код так, что любые проверки разрешений произойдут после того, как некоторые бит данных считываются из POST. Это, похоже, устранило любые симптомы этой проблемы. Это все еще не идеально, но это хорошая альтернатива вставке промежуточного слоя для чтения сообщения. и не всегда будет возможно во всех приложениях.

Прошу прокомментировать, если у вас есть аналогичная ситуация и просто не могу понять это.

Answer 1

Как говорится во второй ссылке в вашем посте, особенно http://forum.nginx.org/read.php?2,196581: когда вы работаете с Nginx и uWSGI и получаете непустую POST, всегда читайте request.POST перед возвратом HttpResponse. Причина описана в ссылке.
Вам не нужно переопределять обработчик, просто введите строку request.POST перед кодом возврата или внутри какого-либо декоратора или промежуточного программного обеспечения.
Я столкнулся с этой проблемой для производственного участка полгода назад и поставил линию в промежуточное программное обеспечение, чтобы решить эту проблему.