問題タブ [django-middleware]

背景: ミドルウェアdjango-multihost(http://effbot.org/zone/django-multihost.htm) を使用して、単一の django アプリが同じプロジェクトの異なるホスト名に応答できるようにしています。ミドルウェアは、 HTTP 要求ヘッダー に基づいてROOT_URLCONF(つまり、どのファイルを) 変更します。urls.pyHost:

これはうまく機能しますが、ページが適切にロードされていることを確認する簡単な統合テストを書きたいと思います。/trendsページが読み込まれるかどうか、および「今日のトレンド」というテキストが表示されるかどうかを確認する基本的なテストの例を次に示します。

問題は、ミドルウェアが呼び出すものではなく、常にデフォルトの ROOT_URLCONF を使用してロードすることです。のようにホスト名を URL に明示的に入れても問題ありませんclient.get("http://secondarysite/trends")。

django テストクライアントを使用して他の仮想サイトでテストするにはどうすればよいですか? そのロジックをテストできるように、テストでミドルウェアを呼び出したいと思います。しかし、必要に応じて、テスト中に ROOT_URLCONF を設定するなどのハッキーなことをしたいと思いますが、その方法がわかりません。

ユーザーが自分のWebサイトにある既存のURLのエイリアスを作成できるURLエイリアスアプリを作成しようとしています。

私はミドルウェアを介してこれを行おうとしています。ミドルウェアではrequest.META['PATH_INFO']、エイリアスのデータベースレコードに対してチェックされます。

ただし、これが正しく機能するためには、（少なくとも）PATH_INFOが宛先パスに変更されることが非常に重要です。

現在、開発者がテストリクエストオブジェクトを作成できるようにするスニペットがいくつかあります（http://djangosnippets.org/snippets/963/、http://djangosnippets.org/snippets/2231/ ）が、これらはそれらが意図されていることを示していますテスト目的。

もちろん、これらのスニペットはライブ環境での使用に適している可能性がありますが、Djangoリクエスト処理に関する私の知識は、これを評価するにはあまりにも開発されていません。

ミドルウェア内で現在のセッションまたはCookieを取得できますか？

試しましたが、次のようになりました。

私のDjangoアプリケーションでは、応答がクライアントに正常に送信されたかどうかを追跡したいと思います。HTTPのようなコネクションレス型プロトコルには、クライアントが応答を受信（および表示）したことを確認する「防水」方法がないことをよく知っています。したがって、これはミッションクリティカルな機能ではありませんが、それでも、可能な限り最新の時間。応答はHTMLではないため、クライアントからのコールバック（JavascriptまたはIMGタグなどを使用）はできません。

私が見つけることができる「最新の」フックは、ミドルウェアリストの最初の位置にprocess_responseを実装するカスタムミドルウェアを追加することですが、私の理解では、これは実際の応答が構築されてクライアントに送信される前に実行されます。応答が正常に送信された後にコードを実行するためのフック/イベントはDjangoにありますか？

いくつかの表示/非表示セクションを含むフォームがあります。ホームフォームでいくつかのボタンを押すと、さまざまなフォームが表示されます。これらのフォームの情報を編集した後、最初のフォームに戻ります。ただし、表示/非表示セクションの状態はリセットされます。表示/非表示アクションは、jquery トグルで行われます。これらのセクションの状態は、戻るときに保持する必要があります。そこで、各セクションの状態をセッション変数に格納しようと考えています。他に解決策はありますか？ミドルウェアなどの別の場所でこの動作を行う方が良いか、可能でしょうか?

フラットページに変換できる複数のモデルがありますが、いくつかの追加情報が必要です（たとえば、私たちについてのページがありますが、ブログもあります）。
ただし、ミドルウェアはフラットページインスタンスのみを返し、子モデルを解決しないため、フラットページモデルは1つだけでなければならないことを理解しています。
私は何をしなければなりませんか？

編集：
ビューを変更する必要があるようです。
現在のコードは次のとおりです。

注：単純化しすぎてサンプルコードが不適切になったため、質問を書き直しました。

これをテストするには、hosts ファイルに次の設定があることを確認してください。

settings.py で、Cookie がサブドメイン全体で機能するように設定します。

次に、次のようなミドルウェアがあります。

私のテンプレートには以下が含まれます：

これをテストするには、開発サーバーでhttp://test.local:8000にアクセスし (メッセージは期待されません)、http://subdomain.test.local:8000にアクセスします ( http://testへのリダイレクトが期待されます)。 .local:8000とメッセージ)。

リダイレクトは表示されますが、メッセージが表示されません。何か不足していますか、それともバグですか?

タプルを取るミドルウェアがあります（ユーザー名の...タプル内のユーザー名のみがサイトの特定の領域を通過できるようにします）。

各ユーザーに関する情報を含む UserProfile モデルがあり、このミドルウェアで使用するユーザー名のタプルを返すようにフィルター処理したいと考えています。つまり、変数 BETA_USERS = (動的に生成されたタプル) を設定します。

これを達成するための提案はありますか？

編集：

したがって、タプルは実際には重要な詳細ではありません。例を次に示します。

通常、これを設定にハードコーディングします。

ただし、1 に設定できる Beta 列を含む UserProfile モデルがあります。ベータ版にサインアップした最初の 50 人は 1 に設定され、それ以外の人は 0 に設定されます。モデル オブジェクトの filter メソッド:

そして、この奇妙な小さなループを使用して、それを素敵なタプルにすることができます。

私の本当の質問は、設定ファイルでこれを呼び出す最良の方法は何ですか?

または、別の言い方をすれば、設定ファイルで動的に作成された変数を割り当てる最良の方法は何ですか?

公式ドキュメントは少し面倒です。「before」と「after」はミドルウェアをタプルで注文するために使用されますが、「before」と「after」が要求/応答フェーズを指す場合もあります。また、「最初/最後である必要があります」が混在しており、どちらを「最初」として使用するかが明確ではありません。

私は違いを理解しています..しかし、Djangoの初心者にとっては複雑なようです。

組み込みのミドルウェアクラスの正しい順序を提案できますか（すべてを有効にすると仮定します）、そして最も重要なこととして、あるクラスが他のクラスの前後にある理由を説明できますか？

これが私が見つけたドキュメントからの情報を含むリストです：

1. UpdateCacheMiddleware
   • 'Vary：'を変更するものの前SessionMiddlewareにGZipMiddleware、、LocaleMiddleware
2. GZipMiddleware
   • 応答本体を変更または使用する可能性のあるMWの前
   • 変更後UpdateCacheMiddleware：「変更：」を変更
3. ConditionalGetMiddleware
   • Before CommonMiddleware：は、次の場合に「Etag：」ヘッダーを使用しますUSE_ETAGS=True
4. SessionMiddleware
   • 変更後UpdateCacheMiddleware：「変更：」を変更
   • 以前TransactionMiddleware：ここではトランザクションは必要ありません
5. LocaleMiddleware、SessionMiddleware、CacheMiddlewareの後の最上位の1つ
   • 変更後UpdateCacheMiddleware：「変更：」を変更
   • 変更後SessionMiddleware：セッションデータを使用
6. CommonMiddleware
   • 応答を変更する可能性のあるMWの前（ETagを計算します）
   • その後GZipMiddleware、gzip圧縮されたコンテンツのEタグは計算されません
   • 上部に近い：APPEND_SLASHまたはPREPEND_WWW
7. CsrfViewMiddleware
   • CSRF攻撃が処理されたと想定するビューミドルウェアの前
8. AuthenticationMiddleware
   • 後SessionMiddleware：セッションストレージを使用
9. MessageMiddleware
   • 後SessionMiddleware：セッションベースのストレージを使用できます
10. XViewMiddleware
11. TransactionMiddleware
    • DBを使用するMWの後: SessionMiddleware(DBを使用するように構成可能）
    • すべて*CacheMiddleWareが影響を受けることはありません（例外として：独自のDBカーソルを使用します）
12. FetchFromCacheMiddleware
    • 'Vary：'を変更するものの後、それらを使用してキャッシュハッシュキーの値を選択する場合
    • その後AuthenticationMiddleware、使用することが可能ですCACHE_MIDDLEWARE_ANONYMOUS_ONLY
13. FlatpageFallbackMiddleware
    • 下：最後の手段
    • ただし、DBを使用することは問題ではありませんTransactionMiddleware （はい？）
14. RedirectFallbackMiddleware
    • 下：最後の手段
    • ただし、DBを使用することは問題ではありませんTransactionMiddleware （はい？）

（このリストに提案を追加して、すべてを1か所に集めます）

ユーザーが一時的なパスワードを使用しているかどうかをキャッチし、使用している場合は新しいパスワードの作成を強制するページにリダイレクトする、小さなミドルウェアを作成しました。私の問題は、ユーザーがログインしていて一時パスワードを使用していない場合 (つまり、手動でパスワード変更 URL に移動した場合) にページが正常に機能することですが、一時パスワードを使用している場合、ミドルウェアからのリダイレクトにより 403 禁止ページが表示されることです。 .

ミドルウェアは、一時パスワードのチェック後に process_view で別の処理を行いますが、関連するコードは次のとおりです。

問題を解決するために、render_to_response などを使用してテンプレートを直接レンダリングすることもできますが、ブラウザの URL が追跡できなくなり、レンダリングしたページを実際に終了できなくなることに注意してください。