no implicit conversion of nil into String caused by update to 'dry' gem

[arimendelow]

Expected behavior

Gem works as expected

Actual behavior

Somewhere in tokenizable, the following error is thrown:
no implicit conversion of nil into String

I see from other issues that this is a common error when the JWT secret isn't set. However, mine is set and I am able to access it in the env variables.

Steps to Reproduce the Problem

1. Run bundle update
2. Attempt to authenticate a user
3. Get the error

Debugging information

I used byebug to step through the code and found that the error was something with dry/concurrent. I was therefore able to fix this issue by undoing the following update in my Gemfile.lock:

(this is a demonstration of the breaking change)

+    dry-auto_inject (0.7.0)
       dry-container (>= 0.3.4)
-    dry-configurable (0.8.3)
+    dry-configurable (0.11.5)
       concurrent-ruby (~> 1.0)
       dry-core (~> 0.4, >= 0.4.7)
-    dry-container (0.7.1)
+      dry-equalizer (~> 0.2)
+    dry-container (0.7.2)
       concurrent-ruby (~> 1.0)
       dry-configurable (~> 0.1, >= 0.1.3)
-    dry-core (0.4.7)
+    dry-core (0.4.9)
       concurrent-ruby (~> 1.0)
+    dry-equalizer (0.3.0)

This is the only difference between a broken setup and a working one.

[waiting-for-dev]

Have you tried running bundle update --source warden-jwt_auth?

[arimendelow]

Yup. I'm already on the latest version of that gem. The problem persists.

[waiting-for-dev]

I thought it was solved. Lock dry-configurable version in the meantime.

[waiting-for-dev]

But it seems no possible... can you double check which warden-jwt_auth version do you have in your Gemfile? Currently it's locking dry-configurable to less than 0.11 but it seems you have 0.11.5.

https://github.com/waiting-for-dev/warden-jwt_auth/blob/0696478cab322bcd1c62e4d20d42d6623c97b0dc/warden-jwt_auth.gemspec#L24

[arimendelow]

Sounds good!

From my Gemfile.lock:

warden-jwt_auth (~> 0.3.6)

I'm not sure, all I did was run bundle update. I don't know why the lock didn't hold.

[waiting-for-dev]

Update to latest version of devise-jwt first, then updating warden-jwt_auth will lead you to 0.4.2, where it's resolved.

[arpu]

still get this problem

TypeError (no implicit conversion of nil into String):
  
jwt (2.2.1) lib/jwt/algos/hmac.rb:14:in `digest'
jwt (2.2.1) lib/jwt/algos/hmac.rb:14:in `sign'
jwt (2.2.1) lib/jwt/algos/hmac.rb:28:in `verify'
jwt (2.2.1) lib/jwt/signature.rb:44:in `verify'
jwt (2.2.1) lib/jwt/decode.rb:42:in `verify_signature'
jwt (2.2.1) lib/jwt/decode.rb:26:in `decode_segments'
jwt (2.2.1) lib/jwt.rb:28:in `decode'

Using warden 1.2.8
Using devise 4.7.1
Using dry-core 0.4.9
Using dry-configurable 0.9.0
Using dry-container 0.7.2
Using dry-auto_inject 0.7.0
Using jwt 2.2.1
Using warden-jwt_auth 0.4.2
Using devise-jwt 0.6.0 from https://github.com/waiting-for-dev/devise-jwt (at master@007d176)

ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]

[arpu]

sorry for the noise found my problem

1. delete old token in localStore
2. create new credentials
   with
   EDITOR="nano" bundle exec rails credentials:edit

[yammusic]

still get this problem

TypeError (no implicit conversion of nil into String):
  
jwt (2.2.1) lib/jwt/algos/hmac.rb:14:in `digest'
jwt (2.2.1) lib/jwt/algos/hmac.rb:14:in `sign'
jwt (2.2.1) lib/jwt/algos/hmac.rb:28:in `verify'
jwt (2.2.1) lib/jwt/signature.rb:44:in `verify'
jwt (2.2.1) lib/jwt/decode.rb:42:in `verify_signature'
jwt (2.2.1) lib/jwt/decode.rb:26:in `decode_segments'
jwt (2.2.1) lib/jwt.rb:28:in `decode'

Using warden 1.2.8
Using devise 4.7.1
Using dry-core 0.4.9
Using dry-configurable 0.9.0
Using dry-container 0.7.2
Using dry-auto_inject 0.7.0
Using jwt 2.2.1
Using warden-jwt_auth 0.4.2
Using devise-jwt 0.6.0 from https://github.com/waiting-for-dev/devise-jwt (at master@007d176)

ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]

I have the same problem, I am using the same gem versions and I have already deleted and created new credentials but it still doesn't work.

Any suggestions?, Thanks

[waiting-for-dev]

@yammusic please if it persists open a new issue with all requested debugging information. Thanks.