Django-rest-framework: 令牌管理页面将访问令牌泄漏到日志文件中

行。 是的。 不理想。

传统上，与令牌相关的问题的答案是提供的实现故意（过度）简单，如果您需要更复杂/更好的东西，您应该使用自定义实现。 （这里的底线是我们避免在这里增加任何复杂性以保持合理的维护负担。）

访问管理页面的用户（高）和查看日志的用户（中）的访问权限是不同的。

我认为对于将/应该在生产中使用提供的实现的人来说，情况并非如此。
（在那些情况下，他们将是同一个人。）

不知道别人会怎么说...

传统上，与令牌相关的问题的答案是提供的实现故意（过度）简单，如果您需要更复杂/更好的东西，您应该使用自定义实现。

我得到了这个职位，但是文档应该强烈建议用户至少远离内置实现，并在极端情况下弃用。 令牌/签名身份验证的第 3 方建议是https://github.com/etoccalino/django-rest-framework-httpsignature，3年未更新。 我想如果不提供开箱即用的第三方令牌提供商，将会有更多的兴趣。

这是一个非常严重的信息泄露 IMO，所以我不确定 authtoken 的默认位置在这种情况下是否正确。

不，这就是我没有关闭它的原因...

抱歉，如果我的回答比预期的更粗鲁，那不是我的目标。

没问题！ 😃

（想知道我们是否可以只修改 ModelAdmin 以在 url 中使用键的哈希...）

鬼鬼祟祟，但这个想法也让人觉得很危险，虽然我说不出为什么。

迁移应该能够处理这项工作。 棘手的一点是其他表中的外键，但这似乎不太可能。 DRF 不会为令牌创建 FK，我也看不出用户会这样做的很多原因。

我不认为我之前尝试过迁移主键字段，但我似乎记得有一个处理它的操作，并且相应的外键也更新了。

对。 它需要数据迁移，但否则我想很容易切换。

欢迎拉取请求。 感谢您的报告！

令牌是否必须是唯一的？

我理解这个问题，但您应该考虑根据您创建的迁移（解决此问题），您可能会导致许多其他问题（例如，引入新的 PK 字段很可能会破坏一些其他依赖于当前行为的包)。

我想知道是否可以在令牌表上添加一个自动增量整数字段，该字段用作 Django 管理页面中 Auth 令牌的引用，但不能作为表的主键？

仅供参考，我刚刚验证了我的扩展令牌实现也有同样的问题（请参阅django-rest-multitokenauth ） - 所以感谢您在管理面板中指出该错误！ 我期待在这里看到解决方案，因此我可以调整我的 python 包。

仅供参考，这就是我在 MultiTokenAuth 包中修复它的方式：
https://github.com/anx-ckreuzberger/django-rest-multiauthtoken/commit/7e11ed606271eff0693a9280f8a30349c7e90b27

我想这里可以应用相同的修复程序，但如果他们有令牌表的外键，可能会破坏其他人的代码

你好，

在为即将进行的项目评估此库之前，我只是浏览了与身份验证相关的问题。 我有一个简单的问题，不胜感激。

可以通过简单地不在管理员中注册 Token 模型来避免这个问题吗？

@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 查看_“引入一些管理员更改”_ 选项。