🧅
Djangoミドルウェア — リクエスト/レスポンスを包む玉ねぎ構造
MIDDLEWARE設定順序がなぜ重要か、内部でどうチェーンされるか
リクエスト：Security → Session → Common → Auth → View
レスポンス：View → Auth → Common → Session → Security
玉ねぎを剥くように入り、皮を着せるように出る。
内部実装
get_responseがチェーンの次のリンク。Djangoがサーバー起動時にMIDDLEWAREリストを逆順で巡回し、各ミドルウェアのget_responseに次のミドルウェアを接続。
順序が重要な理由
SessionMiddlewareがAuthenticationMiddlewareより前になければならない — AuthがセッションからThere情報を読むため。順序を変えるとrequest.userが常にAnonymousになる。
キーポイント
1
MIDDLEWAREリスト順序＝リクエスト処理順序（逆順でチェーン）
2
get_response(request)呼び出しが次のミドルウェア/Viewを実行
3
リクエスト：外→中、レスポンス：中→外（玉ねぎ構造）
4
SessionがAuthより先に来なければrequest.userが動作しない
ユースケース
カスタムロギング — リクエスト/レスポンスを包んで処理時間計測
CORS処理 — CorsMiddlewareがレスポンスヘッダーを追加