“没有可用的验证密钥"；尝试访问由Devise JWT保护的API时 [英] "No verification key available" when attempting to access API secured by Devise JWT

问题描述

我安装了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 $}]，['GET'，％r {^/$}]]jwt.request_formats = {用户:[:json]}jwt.expiration_time = 8.hours.to_i结尾 

我可以正常登录并获得授权令牌:

  blaine @ devbox:〜/langsite/backend [master] $ curl -D--X POST -d"user [email] =[e-mail]& user [password] = blaine"http://localhost:3001/users/sign_in.jsonHTTP/1.1 201已创建X-Frame-Options:SAMEORIGINX-XSS-Protection:1；模式=阻止X-Content-Type-Options:nosniffX-Download-Options:noopenX许可跨域策略:无推荐人政策:严格起源于交叉起源地点:/内容类型:application/json;字符集= utf-8授权:承载eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiIwZWNjMmIzNi04ZmZiLTQ2Y2QtYTZkNi1iZGRjZmU4YTQxNmMiLCJzdWIiOiIxIiwic2NwIjoidXNlciIsImF1ZCI6bnVsbCwiaWF0IjoxNjA1ODQ4MDQ2LCJleHAiOjE2MDU4NzY4NDZ9.66Hg_NG3E79-ybC4rJK_XkkSxpLcWHWTlOiw96hyvjgETag:W/"cfe36cdecee4080492f63e8c8f0c091b"缓存控制:max-age = 0，私有，必须重新验证X-Request-Id:c961fc61-a1b4-49f0-bc16-63f19a0abd22X运行时:0.279213变化:起源传输编码:分块 

似乎我也暴露了Authorization标头:

  Rails.application.config.middleware.insert_before 0，Rack :: Cors做允许做起源'*'资源('*'，标头::any，公开:[授权"]，方法::any)结尾结尾 

我的用户模型:

  class用户<应用记录包括Devise :: JWT :: RevocationStrategies :: JTIMatcher#包括默认的devise模块.其他可用的是:#:可确认，:可锁定，:超时，:可追踪和:omniauthable设计:database_authenticatable，:registerable，:recoverable，:rememberable，:validatable，:jwt_authenticatable，jwt_revocation_strategy:自我结尾 

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

解决方案

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 = [['DELETE'，％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 = [['DELETE'，％r {^/logout $}]]jwt.expiration_time = 2.weeks.to_i结尾 

如果 jwt.secret 为空，则无论出于何种原因，它仍将生成 auth令牌.像您一样，这让我失望了，因为它使我认为我的设置是正确的.

---

要测试是否遇到类似问题，请暂时将乱码作为秘密.如果可行，那么您走在正确的轨道上

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

对我来说，这意味着在 systemd 服务配置中指定一个 EnvironmentFile ，其中包含 key = value 对(非常类似于 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]=[e-mail]&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时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！