Django-rest-framework: トークン管理ページがアクセストークンをログファイルにリークします

わかった。 うん。 理想的ではありません。

トークン関連の質問に対する答えは、従来、提供された実装は意図的に（過度に）単純であり、より複雑でより良いものが必要な場合はカスタム実装を使用する必要があるというものでした。 （ここでの結論は、メンテナンスの負担を合理的に保つために、ここでこれ以上複雑さを追加することを避けたことです。）

管理ページへのアクセス権を持つユーザー（高）とログを表示する権限を持つユーザー（中）のアクセス許可は異なります。

これは、提供された実装を本番環境で使用する/使用する必要がある人には当てはまらないと思います。
（その場合、彼らは同一人物になります。）

他の人が何を言うかわからない...

トークン関連の質問に対する答えは、従来、提供された実装は意図的に（過度に）単純であり、より複雑でより良いものが必要な場合はカスタム実装を使用する必要があるというものでした。

私はこの立場をとっていますが、ドキュメントでは、少なくとも組み込みの実装から離れてユーザーを強く推奨し、極端な場合は非推奨にする必要があります。 トークン/署名認証に関するサードパーティの推奨事項はhttps://github.com/etoccalino/django-rest-framework-httpsignatureであり、3年間更新されていません。 サードパーティのトークンプロバイダーが箱から出して提供されていなければ、もっと多くの関心が寄せられると思います。

これはかなり深刻な情報開示IMOであるため、この場合、authtokenのデフォルトの位置が正しい方法であるかどうかはわかりません。

いいえ、それが私がそれを閉じなかった理由です...

私の応答が意図したよりも粗くなった場合は申し訳ありませんが、それは私の目標ではありませんでした。

問題はありません！ 😃

（ModelAdminを変更して、URLのキーのハッシュを使用できるかどうか疑問に思っています...）

卑劣ですが、その考えも危険だと感じますが、理由はわかりません。

移行はジョブを処理できる必要があります。 トリッキーなビットは他のテーブルの外部キーですが、それはありそうにないようです。 DRFはトークンへのFKを作成しません。また、ユーザーが作成する理由は多くありません。

以前に主キーフィールドを移行しようとしたことはないと思いますが、それを処理する操作があり、対応する外部キーも更新されたことを覚えているようです。

うん。 データの移行が必要ですが、それ以外の場合は、切り替えるのは簡単だと思います。

プルリクエストは大歓迎です。 報告ありがとうございます！

トークンは必ずしも一意である必要がありますか？

問題は理解していますが、（この問題を解決するために）作成する移行によっては、他の多くの問題が発生する可能性があることを考慮する必要があります（たとえば、新しいPKフィールドを導入すると、現在の動作に依存する他のパッケージが破損する可能性があります）。

トークンテーブルに自動インクリメント整数フィールドを追加することは可能でしょうか。これは、認証トークンのDjango管理ページ内で参照として使用されますが、テーブルの主キーとしては使用されません。

参考までに、拡張トークンの実装でも同じ問題があることを確認しました（ django-rest-multitokenauthを参照）。管理パネルでその間違いを指摘していただきありがとうございます。 ここで解決策を見るのを楽しみにしているので、Pythonパッケージを適応させることができます。

参考までに、これは、MultiTokenAuthパッケージ内で修正した方法です。
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

トークンテーブルへの外部キーを持っている場合、他の人のコードを壊す可能性があるという警告とともに、同じ修正をここに適用できると思います

こんにちは、

今後のプロジェクトでこのライブラリを評価する前に、認証関連の問題をざっと見ていたところです。 簡単な質問があります。助けていただければ幸いです。

トークンモデルをadminに登録しないだけで、この問題を回避できますか？

@raunaqssはい、登録する必要はありません。

これを再上げてくれてありがとう。

これでどちらの方向に進んでいるかわかりますか？
URLをハッシュするか、PKを移行する必要がありますか？

PRできます。

ここでは、移行が賢明なアプローチになる可能性が非常に高くなります。
たとえば、3.11リリースに移行を含めることについてはかなり警戒しています。 APIキーテーブルが非常に大きい場合は、問題が発生する可能性があります。
おそらく、これへの移行を個別にリリースすることから始めるのが賢明だと思います。そうすれば、リリースとは関係なく、最初にすべてをテストできるようになります。
すべてに満足したら、移行を直接含めることを検討できます。

3.11リリース自体にプッシュするのではなく、これの移行を個別にリリースする方法を見てみましょう。 メジャーリリースですべてのユーザーに移行をプッシュするには、非常に大きなAPIキーテーブルを持つユーザーへの影響に警戒しすぎています。

この問題は長い間開かれており、 @ jarshwahの観察はdjango-rest- knoxによって対処されているように見えますが、デフォルトでより安全にしたいと考えています。 drfの意図がTokenAuthenticationを単純にすることであったとしても、多くの開発者は安全でない認証メカニズムを実装することになります。 設計上秘密の資料を漏らすコードを箱から出して含めるべきかどうかはわかりません。

この問題の解決に進展はありましたか？ 誰かがこの問題で報奨金を受け取ることにオープンですか？ もしそうなら、私はコードを提供したり、賞金を払ったりすることに興味があります。

3.12で優先します。

コードの寄稿に興味があります

確かに、PRを発行することを歓迎します。

もしそうなら、私はコードを提供したり、賞金を払ったりすることに興味があります。

スポンサーになることは貢献する良い方法です。 スポンサーは優先的にサポートされており、必要に応じて問題をエスカレートできます。 https://fund.django-rest-framework.org/topics/funding/#corporate -plans

それはすべて素晴らしいですね！ 私は現在、drfとencodeのスポンサーです。 解決策の作業を開始した場合は、必ずこの問題を更新します。

素晴らしい、どうもありがとうございました。 🙏

さて、これに優雅に取り組む方法は本当に明らかではありません。

モデルで主キーに自動インクリメントintを使用し、「key」フィールドを標準の一意のインデックス付きフィールドにする必要がありますが、それに移行することはできません。 だから私たちのオプションは何ですか...

• rest_framework.authtoken2のようなものを導入し、代わりにドキュメントでそれを参照するようにして、新しいプロジェクトがより適切なデフォルトのセットを取得できるようにすることができます。
• 既存のフィールドを引き続きPKとして使用し、実際のトークン値の新しいフィールドを追加することができます。 値をコピーするデータ移行を導入できるかどうかは明らかではありませんか？ 既存のデータセットが大きいユーザーにとっては問題があります。 これはまともなように見えます... https：//stackoverflow.com/questions/41500811/copy-a-database-column-into-another-in-django移行されていないコードベースの正しい動作にもかなり注意する必要があります。 デプロイされたアプリで作業している場合、通常は新しいフィールドを導入し、コードベースが一定期間古いフィールドを参照するようにしながら、両方のフィールドに同じ値を書き込んでいることを確認します。 そして、それがすべてデプロイされて同期されたら、新しいフィールドを使用するようにコード変更を切り替えます。
• そのまま続行できますが、管理者の変更をいくつか導入します。

誰かがこれについて予備的な考えを持っていますか？

また：これがこれが長い間保留されている理由です-それに対する簡単な答えはありません。 😬

_「管理者の変更を導入する」_オプションを確認するために＃7341を開きました。