にリストされているものと同様の問題があります
POST データが送信され、モデルがアクセスされると、Django は空白のページを生成します
と
Nginx 接続のリセット、uWsgi からの応答が失われました
問題のビューの 1 つを次に示します。
@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 はトランザクションをロールバックし、JSON を内容とする HttpResponse を返します。
アプリケーションの多くのビューにパーミッション チェックを追加していますが、ユーザーが正しいパーミッションを持っていない場合、空白の応答が返されます。
ただし、上記の質問のように、
print request
また
request.POST
パーミッション チェックの前にステートメントを実行すると、NO_PERMISSION_MSG JSON 文字列が毎回正しくブラウザーに返されます (error_response_rollback は、JSON を含む HttpResponse オブジェクトを返します)。
「印刷要求」の前に権限を確認すると、空白の応答が返され、正しい権限がありません。
次の場合、空白の応答は返されません。
- ユーザーは適切な権限を持っています
- 「印刷要求」ステートメントは、許可チェックの前にあります
- いつでも Firefox を使用できます。
@occ_update および @checks_status デコレーターは例外をキャッチするだけです。これらの問題は、存在する場合と存在しない場合に発生します。
私は Chrome で開発していますが、これは Firefox の問題ではありません。
ビューに渡される前にリクエストを読み取るために WSGIRequest オブジェクトをオーバーロードすることを提案しているページが見つかりましたが、これは私には厄介なようで、実際の解決策を見つけたいと思います。
リクエストをハッキングせずにこの問題を解決するための runserver コマンドの修正/設定を知っている人はいますか? ユーザーは主に Chrome を使用しているため、引き続き使用したいと考えています。現在、Django 1.3.1 を使用して Windows で開発中
私が検討したオプションの 1 つは、これを処理する別の manage.py コマンドを作成することですが、それも厄介なようです。
ありがとう
アップデート:
POST から一部のデータが読み取られた後にパーミッション チェックが行われるように、コードを再編成することができました。これにより、この問題の症状が解消されたようです。これはまだ理想的ではありませんが、投稿を読むためにミドルウェアを挿入する代わりの良い方法です。すべてのアプリケーションで常に可能であるとは限りません。
似たような状況でわからないことがあればコメントください。