4

リソースを作成するTastypieAPIに対してPOSTリクエストを実行しています。通常、応答のLocationヘッダーを介してリソースURIを返します。私が抱えている問題は、最初のリクエスト（およびアプリケーション全体）がhttpsの下にあるにもかかわらず、Locationヘッダーに非SSLURLが含まれていることです。

私のリクエストヘッダーから：

URL: https://example.com/api/v1/resource/

私の応答ヘッダーから：

Location: http://example.com/api/v1/resource/80/

これは再利用可能なアプリケーションであり、常にsslで実行されているわけではないため、醜い文字列置換をハードコーディングしたくありません。また、httpからhttpsへの301リダイレクトがすでに設定されていますが、リダイレクトが発生しないようにします。

すべての助けに感謝します！

更新： これは実際にはTastypieとは何の関係もありませんでした。これは、サーバー/プロキシの構成が原因でした。解決策の詳細については、以下の回答を参照してください。

4

1 に答える 1

6

理由は単純です。あなたの場合は一見request.is_secure()返されるように見えるFalseので、URLはのhttp代わりにを使用して構築されますhttps。

いくつかの解決策がありますが、最初に何が原因request.is_secure()で戻ってきたかを見つける必要がありますFalse。プロキシまたはロードバランサーの背後で実行されているに違いありません。URL生成の背後にあるロジックを変更しなかった場合は、これが問題の原因である可能性があります。

これを修正するには、プロキシまたはロードバランサーで確立されたSSL接続を示すヘッダーを定義するSECURE_PROXY_SSL_HEADERDjangoの設定を確認できます。

ただし、Djangoアプリがプロキシの背後にある場合、プロキシは、プロキシとDjango間の非HTTPS接続を使用して、リクエストがHTTPSであるという事実を「飲み込んで」いる可能性があります。この場合、エンドユーザーがHTTPS経由で行ったリクエストであっても、is_secure()常に戻ります。False

この状況では、リクエストがHTTPS経由で受信されたかどうかをDjangoに通知するカスタムHTTPヘッダーを設定するようにプロキシを構成し、SECURE_PROXY_SSL_HEADERDjangoが検索するヘッダーを認識できるように設定する必要があります。

ただし、再利用可能なアプリを設計していて、上記が正しい場合は、それが何か違いがないことを確認してください。これが当てはまると確信している場合は、それをユーザーに任せてください。安全なリクエストの表示を担当するヘッダーは、アプリを使用するプログラマーのみが明示的に設定する必要があります。そうでなければ、これはセキュリティの問題を意味する可能性があります。

于 2012-09-27T17:34:26.133 に答える