“没有可用的验证密钥"尝试访问由 Devise JWT 保护的 API 时

问题描述

我安装了 gem devise-jwt.我可以执行登录请求，并收到一个授权令牌作为回报，但是当我尝试访问安全端点时，我收到消息:没有可用的验证密钥.

布莱恩@ devbox:〜/langsite/后端[主] $卷曲-H"授权:承载eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwZWNjMmIzNi04ZmZiLTQ2Y2QtYTZkNi1iZGRjZmU4YTQxNmMiLCJzdWIiOiIxIiwic2NwIjoidXNlciIsImF1ZCI6bnVsbCwiaWF0IjoxNjA1ODQ2NjczLCJleHAiOjE2MDU4NzU0NzN9.ZyqvylXeLZbrRM2V2s5qsyHxiGgElng58HwQ8qjOHCU"http://localhost:3001/quiz_sentences.json{错误":没有可用的验证密钥"}

这是我在 config/initializers/devise.rb 文件中的内容:

config.jwt 做 |jwt|jwt.secret = Rails.application.credentials.secret_key_jwtjwt.dispatch_requests = [['POST', %r{^/users/sign_in$}],['获取'，%r{^/$}]]jwt.request_formats = { 用户:[:json] }jwt.expiration_time = 8.hours.to_i结尾

我可以正常登录并收到授权令牌:

blaine@devbox:~/langsite/backend [master] $ curl -D - -X POST -d "user[email][email protected]&user[password]=blaine"http://localhost:3001/users/sign_in.jsonHTTP/1.1 201 创建X-Frame-Options: SAMEORIGINX-XSS-保护:1；模式=块X-Content-Type-Options: nosniffX-下载-选项:noopenX-Permitted-Cross-Domain-Policies: 无推荐人政策:严格来源时跨来源地点:/内容类型:应用程序/json；字符集=utf-8授权:承载eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwZWNjMmIzNi04ZmZiLTQ2Y2QtYTZkNi1iZGRjZmU4YTQxNmMiLCJzdWIiOiIxIiwic2NwIjoidXNlciIsImF1ZCI6bnVsbCwiaWF0IjoxNjA1ODQ4MDQ2LCJleHAiOjE2MDU4NzY4NDZ9.66Hg_NG3E79-ybC4rJK_XkkSxpLcWHWTlOiw96hyvjgETag:W/cfe36cdecee4080492f63e8c8f0c091b"缓存控制:max-age=0，私有，必须重新验证X 请求 ID:c961fc61-a1b4-49f0-bc16-63f19a0abd22X 运行时:0.279213变化:起源传输编码:分块

似乎我也公开了 Authorization 标头:

Rails.application.config.middleware.insert_before 0, Rack::Cors 做允许做起源'*'资源('*',标题::任何，暴露:[授权"]，方法::任何)结尾结尾

我的用户模型:

class User 

我很困惑，任何帮助表示赞赏.谢谢.

解决方案

TLDR;确认 jwt.secret 实际上正在设置

我遇到了同样的问题，在我的情况下，这是因为在通过 systemd 启动 Puma 时，jwt.secret 没有被正确读取.

config.jwt do |jwt|jwt.secret = ENV['JWT_SECRET_KEY'] # 为空，仅当通过 systemd 或其他守护进程启动时jwt.dispatch_requests = [['POST', %r{^/login$}]]jwt.revocation_requests = [['删除', %r{^/logout$}]]jwt.expiration_time = 2.weeks.to_i结尾

---

出于某种原因，在远程服务器上，通过 systemd 服务启动时，env['JWT_SECRET_KEY'] 为空.但是，手动启动 Puma 时，它运行良好.

我通过硬编码一个字符串作为秘密发现了这一点.突然就成功了.

config.jwt do |jwt|jwt.secret =012345678901234567890123456789"#突然工作jwt.dispatch_requests = [['POST', %r{^/login$}]]jwt.revocation_requests = [['删除', %r{^/logout$}]]jwt.expiration_time = 2.weeks.to_i结尾

如果 jwt.secret 为空，它仍然会出于任何原因生成一个 auth token.像你一样，这让我很失望，因为它让我认为我的设置是正确的.

---

要测试您是否遇到类似问题，请暂时将乱码硬编码为秘密.如果可行，那么您就走对了

显然，您不应该对字符串进行硬编码，而应该查看并确认您的密码是否正确输入到上述配置中.

对我来说，这意味着在包含 key=value 对的 systemd 服务配置中指定一个 EnvironmentFile(很像一个 dotenv 文件).

I have the gem devise-jwt installed. I can perform a login request, and receive an Authorization token in return, but when I try to access a secured endpoint, I receive the message: No verification key available.

blaine@devbox:~/langsite/backend [master] $ curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwZWNjMmIzNi04ZmZiLTQ2Y2QtYTZkNi1iZGRjZmU4YTQxNmMiLCJzdWIiOiIxIiwic2NwIjoidXNlciIsImF1ZCI6bnVsbCwiaWF0IjoxNjA1ODQ2NjczLCJleHAiOjE2MDU4NzU0NzN9.ZyqvylXeLZbrRM2V2s5qsyHxiGgElng58HwQ8qjOHCU" http://localhost:3001/quiz_sentences.json
{"error":"No verification key available"}

This is what I have in my config/initializers/devise.rb file:

config.jwt do |jwt|
    jwt.secret = Rails.application.credentials.secret_key_jwt
    jwt.dispatch_requests = [
        ['POST', %r{^/users/sign_in$}],
        ['GET', %r{^/$}]
    ]
    jwt.request_formats = { user: [:json] }
    jwt.expiration_time = 8.hours.to_i
end

I can log in just fine and receive an Authorization token:

blaine@devbox:~/langsite/backend [master] $ curl -D - -X POST -d "user[email][email protected]&user[password]=blaine" http://localhost:3001/users/sign_in.json
HTTP/1.1 201 Created
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: strict-origin-when-cross-origin
Location: /
Content-Type: application/json; charset=utf-8
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwZWNjMmIzNi04ZmZiLTQ2Y2QtYTZkNi1iZGRjZmU4YTQxNmMiLCJzdWIiOiIxIiwic2NwIjoidXNlciIsImF1ZCI6bnVsbCwiaWF0IjoxNjA1ODQ4MDQ2LCJleHAiOjE2MDU4NzY4NDZ9.66Hg_NG3E79-ybC4rJK_XkkSxpLcWHWTlOiw96hyvjg
ETag: W/"cfe36cdecee4080492f63e8c8f0c091b"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: c961fc61-a1b4-49f0-bc16-63f19a0abd22
X-Runtime: 0.279213
Vary: Origin
Transfer-Encoding: chunked

It seems that I have the Authorization header exposed as well:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
    allow do
        origins '*'
        resource('*',
            headers: :any,
            expose: ["Authorization"],
            methods: :any
        )
    end
end

My user model:

class User < ApplicationRecord
    include Devise::JWT::RevocationStrategies::JTIMatcher
    # Include default devise modules. Others available are:
    # :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
    devise :database_authenticatable, :registerable, :recoverable,
    :rememberable, :validatable, :jwt_authenticatable, jwt_revocation_strategy: self
end

I'm pretty much baffled, any help appreciated. Thanks.

解决方案

TLDR; Confirm jwt.secret is actually being set

I had this same issue, in my case it was caused because the jwt.secret was not being read correctly, when starting Puma via systemd.

config.jwt do |jwt|
 jwt.secret = ENV['JWT_SECRET_KEY'] # was blank, only if starting via systemd or other daemon
 jwt.dispatch_requests = [
   ['POST', %r{^/login$}]
 ]
 jwt.revocation_requests = [
   ['DELETE', %r{^/logout$}]
 ]
 jwt.expiration_time = 2.weeks.to_i
end

---

For some reason, on the remote server, when launching via systemd service, env['JWT_SECRET_KEY'] was empty. However, when starting Puma manually, it worked fine.

I found this out, by hard coding a string as the secret. Suddenly it worked.

config.jwt do |jwt|
 jwt.secret = "012345678901234567890123456789" # Suddenly worked
 jwt.dispatch_requests = [
   ['POST', %r{^/login$}]
 ]
 jwt.revocation_requests = [
   ['DELETE', %r{^/logout$}]
 ]
 jwt.expiration_time = 2.weeks.to_i
end

If jwt.secret is empty, it will still generate an auth token for whatever reason. Like you this threw me off, as it made me assume my setup was correct.

---

To test if you're running into a similar issue, temporarily hardcode gibberish as the secret. If that works, then you're on the right track

Obviously you should not hard code the string, but rather look into and confirm that your secret is being fed correctly into the above config.

For me that meant specifying an EnvironmentFile in the systemd service configuration which contains key=value pairs (much like a dotenv file).

这篇关于“没有可用的验证密钥"尝试访问由 Devise JWT 保护的 API 时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！