【问题标题】:The key was not found in the key ring. Unable to validate token在钥匙圈中找不到钥匙。无法验证令牌
【发布时间】:2020-11-28 16:04:46
【问题描述】:

在我的应用程序前面添加 NGNIX 代理后,我在身份服务器 4 上遇到了奇怪的错误。

  1. 我的 .net 核心身份服务器正在 Docker 容器的 8080 端口上运行

  2. Ngnix 代理(使用https://github.com/nginx-proxy/nginx-proxy)配置为将 443 路由到 docker 容器 8080

在回调端点上成功验证后,它无法验证伪造令牌。

奇怪的部分是整个场景适用于我在启动 .net 核心应用程序时播种的用户。但是对于通过我的 API 创建的新的失败。

感谢任何想法或教导。

【问题讨论】:

  • 请通过指定更多信息来增加问题的清晰度,例如引发错误或意外结果的代码行。
  • 请改进问题并指定您在哪个 URL/页面上收到该错误。发布失败网址的副本也会有所帮助

标签: .net docker identityserver4


【解决方案1】:

由 ASP.NET 核心发布的会话 cookie 使用数据保护 API 进行加密。

用于签署 cookie 的密钥存储在密钥环中。如果您现在重新部署您的应用程序并且您没有正确配置它,那么新的加密密钥将在一个新的密钥环中发布。

如果无法找到用于加密 cookie 的密钥,则意味着所有客户端浏览器中的现有会话 cookie 无法再解密。

请参阅此article 了解此 API 和此article 了解如何配置它。

这适用于您的 IdentityServer 和客户端应用程序,因为它们都使用数据保护 API,因此两者都需要有一个永久密钥环。当您重新部署容器时,密钥环会丢失,除非您已将密钥环放置在文件系统上的某个永久卷中或以其他方式将其持久化。 API 支持很多地方存储密钥环,包括数据库、redis、Azure Key Vault..

【讨论】:

  • 牢记这一点,我还尝试将密钥存储在文件系统中
  • 更新了我的答案,有帮助吗?或者这不是你的问题?
  • 我已经解决了 nginx 代理缓冲区的问题。通过 (medium.com/@mshanak/…) 修复
  • 太棒了!你知道核心问题是什么吗?你的会话 cookie 太大了吗?
  • 我的客户端请求头大于 1K 字节。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-05-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多