ミドルウェア

revision-up-to:17812 (1.4)

このドキュメントでは、 Django に付属している全ミドルウェアコンポーネントに ついて解説しています。ミドルウェアの使い方や自作のミドルウェアの書き方は ミドルウェアの使い方ガイド を参照してくださ い。

利用できるミドルウェア

キャッシュミドルウェア

class UpdateCacheMiddleware
class FetchFromCacheMiddleware

サイト全体にわたるキャッシュを有効にします。キャッシュを有効にすると、 Django の管理下にあるページは CACHE_MIDDLEWARE_SECONDS 設定に定 義した時間のキャッシュされます。 キャッシュのドキュメント を参照してください。

コモンミドルウェア

class CommonMiddleware

リクエスト処理に完全主義者むけの便宜機能を追加するミドルウェアです:

  • DISALLOWED_USER_AGENTS に設定されたユーザエージェントから のアクセスを禁止します。 DISALLOWED_USER_AGENTS には文字列 のリストを指定します。

  • APPEND_SLASH および PREPEND_WWW に基づいて URL の書き換えを行います。

    APPEND_SLASHTrue の場合、リクエストの URL の末尾が スラッシュで終わっておらず、 URLconf 上でもマッチしなければ、 スラッ シュを付加した URL を作成して、 URLconf でマッチするか確かめます。マッ チすれば、スラッシュつきの URL にリダイレクトします。そうでなければ、 URL を通常の手順に従って処理します。

    例えば、 foo.com/bar に一致するパターンがなく、 foo.com/bar/ に一致するパターンが あればfoo.com/barfoo.com/bar/ にリダイレクトされます。

    PREPEND_WWWTrue であれば、先頭に, “www.” のない URL は先頭に”www.” を付けた URL にリダイレクトします。

    それぞれのオプションは URL を正規化するためのものです。これは、 URL (Uniform Resorce Location) がただひとつの、真にただひとつの場所 (Location) を表すべきであるという哲学に基づいています。技術的には、 foo.com/barfoo.com/bar/ とは別物です – 例えば、検索エン ジンはこの二つの URL を別々の URL として扱うかもしれません – ですか ら、 URL を正規化しておく方が得策なのです。

  • SEND_BROKEN_LINK_EMAILSTrue の場合、 MANAGERS にリンク切れ報告のメールを送信します。

  • USE_ETAGS 設定に基づいて ETag を処理します。 USE_ETAGSTrue に設定すると、 Django は各リクエスト ごとにページ内容の MD-5 ハッシュを計算して ETag にし、必要なら Not Modified 応答を返します。

ビューメタデータミドルウェア

class XViewMiddleware

INTERNAL_IPS 設定に定義されている IP アドレスから来た HEAD リク エストに対してカスタムの X-View HTTP ヘッダを送信します。このミドルウェ アはDjango の 自動ドキュメントシステム で使われています。 これは AuthenticationMiddleware に依存 しています。

GZip ミドルウェア

class GZipMiddleware

GZip 圧縮を受け付けるブラウザ (最近のほとんどのブラウザがそうです) 向けに、 コンテンツを圧縮して送ります。

このミドルウェアは、ミドルウェアリストの先頭に置くよう勧めます。なのでレスポンス コンテンツの圧縮は最後に行われます。

以下のいずれかの場合にはコンテンツを圧縮しません:

  • コンテンツボディーが 200 バイト長未満の場合。
  • レスポンスに Content-Encoding ヘッダがすでに設定されている場合。
  • (ブラウザの) リクエストが、 gzip を含む Accept-Encoding ヘッダーを 送らなかった場合。
  • Internet Explorer からのリクエストで、 Content-Type ヘッダが javascript か、 text/ 以外から始まるものを持っている場合。 IE の古いバージョンにあるバグを避けるためです。特定のコンテンツタイプで 実行されるべきではない解凍を引き起こすからです。

個別のビュー GZip 圧縮 を使いたい場合は gzip_page() デコレータを使いましょう。

条件付き GET ミドルウェア

class ConditionalGetMiddleware

条件付き GET 操作を処理します。レスポンスに ETag または Last-Modified ヘッダがあり、リクエストに If-None-Match または If-Modified-Since がある場合、レスポンスを HttpNotModified に置き換えます。

また、 Date および Content-Length ヘッダを設定します。

リバースプロキシミドルウェア

class SetRemoteAddrFromForwardedFor

このミドルウェアは Django 1.1 で廃止されました。詳細は リリースノート を 参照してください。

ロケールミドルウェア

class LocaleMiddleware

リクエストに基づいて言語の選択を行います。言語の選択によって、ユーザごとに 提供するコンテンツをカスタマイズできます。 国際化のドキュメント を参照してください。

メッセージミドルウェア

class MessageMiddleware
Django 1.2 で新たに登場しました: MessageMiddleware が追加されました。

クッキー、セッションベースのメッセージがサポートされました。 messages documentation を参照してください。

セッションミドルウェア

class SessionMiddleware

セッションのサポートを有効にします。 セッションのドキュメント も参照してください。

認証ミドルウェア

class AuthenticationMiddleware

入力される HttpRequest オブジェクト全てに、現在ログインしているユーザを 表す user 属性を追加します。 Web リクエストの認証 を参照してください。

CSRF 対策ミドルウェア

class CsrfViewMiddleware

POST フォームに隠しフォームフィールドを追加し、リクエストデータに正しい値が 設定されているかチェックすることによりクロスサイトリクエストフォージェリ (CSRF) を防ぎます。詳しくは クロスサイトリクエストフォージェリからの保護 を参 照してください。

トランザクションミドルウェア

class TransactionMiddleware

リクエスト/レスポンス処理フェイズに commit と rollback をバインドします。 あるビュー関数の実行に成功した場合に commit を、例外を送出して失敗した場合 には rollback を行わせます。

このミドルウェアでは、スタック中の順番が重要になります。このミドルウェアの 外で動作する他のミドルウェアモジュールは、Django のデフォルトの挙動、すなわ ち commit-on-save モードで動作します。このミドルウェアの内側にある (スタッ クの後ろに位置している) ミドルウェアは、ビュー関数と同じトランザクション制 御下に置かれます。

トランザクション管理のドキュメント を参照し てください。

X-Frame-Options middleware

class XFrameOptionsMiddleware
Django 1.4 で新たに登場しました: XFrameOptionsMiddleware が追加されました。

単純な X-Frame-Options ヘッダによるクリックジャッキング対策