Django-rest-framework: DRFは、デフォルトですべてのOPTIONSリクエストを承認する必要があります

DRFバージョン：3.7.3
Python 3.6.3

上記の一時的な回避策は私にはうまくいきませんでした。 すべてのリクエストは、PUT、POST、GET、OPTIONSなどであるかどうかに関係なく認証されていました。

それはそれを次のように変更することに取り組みました：

# myapp/permissions.py
from rest_framework.permissions import IsAuthenticated

class AllowOptionsAuthentication(IsAuthenticated):
    def has_permission(self, request, view):
        if request.method == 'OPTIONS':
            return True
        return request.user and request.user.is_authenticated

そしてsettings.pyで：

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': ( 'rest_framework.authentication.TokenAuthentication',),
    'DEFAULT_PERMISSION_CLASSES': (
        'myapp.permissions.AllowOptionsAuthentication',
    )
}

私もこれと同じ問題に遭遇しました。 私は提案された解決策に同意し、一時的な回避策に感謝します！

「デフォルトですべてのOPTIONSリクエストを承認すべきである」と確信していない100％が正確に使用RESTフレームワークを使用する開発者の多くがあるので、私たちが望む動作ですOPTIONS CORSプリフライトリクエスト以外の場合のための要求が。

ただし、おそらく、祝福されたCORSオプションが必要だと思います。 それがhttps://github.com/ottoyiu/django-cors-headers/を直接含める必要があるのか​​、それとももっと高度に参照する必要があるのか​​はわかりません。

この問題は、そのパッケージを使用すると解決しますか？

このパッケージは実際には解決策ではなく、CORSヘッダーを追加するだけですが、認証されていないすべてのリクエストに対してDRF権限が明確に付与されていない場合、OPTIONSがHTTP401を返すという事実を修正しません。

IMOは逆に導入する必要があります。つまり、デフォルトで重大な変更通知で許可されます。
これはW3C仕様によると予想される動作であり、ドキュメントでサードパーティに言及して間違った実装にパッチを適用することは、実際にはクリーンな解決策ではありません...

したがって、CORSに関連しないものにOPTIONSを使用している人もいますが（私もその1人です）、CORSメカニズムがますます多くのブラウザーによって適用されているため、箱から出してすぐに機能することを暗黙のうちに期待している可能性があります。 実際、これらのメカニズムは、Web上で99％以上のOPTIONSリクエストを生成する可能性があります。

興味深い対立。 OPTIONSメソッドにデフォルトで暗黙的な許可を設定することの問題を完全に理解しています。 私は当然、より安全なソリューションに偏っています。それは、開発者のDRFの目的に依存すると思います。 したがって、デフォルトの拒否が私にはより適切であるように思われます。

OPTIONSを許可するためのW3C仕様が、CORSのコンテキストでのみ適用される可能性もあります。 明らかに、DRFにはコンテキストを知る方法がなく、開発者に提供される設定である必要があります。

CORSが意図されている場合は、すべてのOPTIONSリクエストを許可します。 CORSはデフォルトでは意図されていません。

実際、現在の動作を利用したまま、メジャーバージョンの重大な変更を検討できると思います。 JSONPはCORSではなくJSONPが使用するものであったため、既存のOPTIONSの動作は適切に行われているため、公開するデフォルト情報のかなりアドホックなセットを削除し、代わりにデフォルトでCORSのOPTIONSのみに集中する更新が必要になる可能性があります。 。

+1

@tomchristieメジャーバージョンの更新/修正がいつ行われるかについて何か考えがありますか？ 私もこの問題にぶつかっています。

一方、 @ medakkの回避策は完璧です。

これをマイルストーンして、3.9の適切な考慮事項を確実に取得する

別の回避策は、ビューでこれを明示的に処理することです。 複数のpermission_classesがある場合、それぞれがこの処理を必要とするため、これはよりDRYです。

def check_permissions(self, request):
        if request.method == 'OPTIONS':
            return
        super(MyApiView, self).check_permissions(request)

さらに詳しく調べて、これに戻ります。https：//github.com/OttoYiu/django-cors-headersパッケージは、ミドルウェアでプリフライトされたOPTIONSリクエストを処理し、応答を直接返します。 要求/応答はRESTフレームワークに到達する前にインターセプトされるため、ここでRESTフレームワークが何を行うかは重要ではありません。

ここに問題があることは私にはわかりません。

プリフライト応答はRESTフレームワークに影響を与えません： https ：

ありがとう。 django-cors-headersは使用していませんが、使用する必要があるかもしれません。
私は、DRFがW3C準拠のCORS要求を処理するために外部パッケージを必要とすべきではないという以前のコメントにまだ同意します。

はい、問題を回避するための方法/サードパーティパッケージがたくさんあります。
ただし、このチケットは、DRFがW3C CORS仕様と互換性がないために作成されたものであり、修正する必要があります。

現在、エンドポイントに対して実行されるOPTIONSリクエストの大部分はプリフライトの目的であり、DRFの意見による選択のために、新しいDRFユーザーがこれらの問題を手動で処理しなければならないことはおそらく欺瞞的です。

現在、エンドポイントに対して実行されるOPTIONSリクエストの大部分はプリフライトの目的であり、DRFの意見による選択のために、新しいDRFユーザーがこれらの問題を手動で処理しなければならないことはおそらく欺瞞的です。

CORSがOPTIONSメソッドをハイジャックしたからといって、それに対応するためにデフォルトでセキュリティを変更する必要があるわけではありません。 特にCORSサポートが適切に実装されている場合は、必要な方法で機能します。 申し訳ありませんが、これを変更したい開発者は、DRFメンテナではなく、自分の意見を確認する必要があると思います。

おそらく、CORSが必要な場合は、車輪の再発明の代わりに、適切な実装を支援するモジュールを使用することを提案するドキュメントの拡張。

レベルを下げましょう。

ミドルウェアは、CORSヘッダーを処理するための賢明な場所です。 これをRESTフレームワークに組み込むこともできますが、既存のパッケージにはすでに非常にうまくカバーされています。

プリフライトされたCORSリクエストはミドルウェアによってインターセプトされる必要があり、標準のCORSリクエストは任意のHTTPメソッドである可能性があるため、RESTフレームワークがOPTIONSリクエストに対してたまたま返す本体はここでは関係ありません。

RESTフレームワークがデフォルトでこれらの応答本文を提供しないように移行することを完全に嬉しく思いますが、それはCORSサポートの問題とは少し異なり、RESTフレームワークがそこでの動作について意見を述べているほどではなく、 CORSが広く実装される前の動作。

ミドルウェアソリューションだけでは不十分であるか、少なくともDRFの協力が必要であるように思われます。 参照されているコードを見ると、CORSヘッダーを提供するためにグローバルデフォルトが使用されていることがわかります。 しかし、各ビューがサポートするヘッダーをグローバルに知るにはどうすればよいですか？

そのため、ミドルウェアがビューセット/ビューからこれらの構成オプションにフックする標準的な方法を確認したいと思います。たとえば、 allowed_cors_headersメソッドです。

これはビューで処理する必要はないことに同意しますが、ビューが何を提供できるかについてのビューの知識を絶対に尊重する必要があります。

ルーター内のすべてのビューに適用するルーターレベルのオーバーライドを設定することも価値がある場合があります。

追加の考慮事項：

• 起源に基づいて変化する
• コンテンツタイプによって異なります

これは私のお気に入りの選択ではありませんが、サードパーティを使用する傾向にあります。

ドキュメントがCORSユーザー向けの適切な情報で更新されたら、このチケットを閉じることができると思います（たとえば、「DRFはOPTIONSリクエストのW3C CORS仕様を満たしていません。OPTIONSforCORSを使用する場合は、忘れずに追加してください。適切なミドルウェア。そうしないと、承認がないためにプリフライトリクエストが失敗する可能性があります」など）

既存のドキュメントhttps://www.django-rest-framework.org/topics/ajax-csrf-cors/#corsは完全に合理的であり、ミドルウェアでCORSを

しかし、各ビューがサポートするヘッダーをグローバルに知るにはどうすればよいですか？

あなたはする必要はありません-あなたはサイトのCORSポリシーが何であるかを知る必要があります。

CORSドキュメントをより目立たせる、または適切な別の場所に含めるプルリクエストを喜んで受け入れます。 それ以外は、ここで実行可能な問題はありません。

スペックの私の誤解、おっと。

その場合、サポートはdjangoサイトのcontribに含まれる方がよいでしょう。
drfではなくパッケージ。

ルマール。 19févr。 2019 10:22 am、Tom Christie [email protected] a
écrit：

既存のドキュメント
https://www.django-rest-framework.org/topics/ajax-csrf-cors/#corsは
完全に合理的であり、ミドルウェアでCORSを処理することは正しいです
いずれにせよアプローチ。

しかし、各ビューがサポートするヘッダーをグローバルに知るにはどうすればよいですか？

あなたはする必要はありません-あなたはサイトのCORSポリシーが何であるかを知る必要があります。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/encode/django-rest-framework/issues/5616#issuecomment-465146969 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFhtlM6bG-Bs2CvoO972pIfwvxLHbzAxks5vPAjAgaJpZM4Qlvkn
。