Allow passing current time to `decode`

[seadowg]

👋 Hi! Thanks for creating such a simple to use JWT library.

One problem I've run into is that when using the exp functionality I am unable to write tests around expiration scenarios without using time-bending libraries such as Timecop. This isn't the worst thing in the world but I often find I end up in confusing scenarios due to losing the explicit control of what time is being passed to the method under test.

I'm happy to work on a PR if so but I was wondering if there are thoughts around being able to pass the current time to decode. Is this a change that would be accepted? If so, are there ideas around how it should be part of the decode signature?

[excpt]

Hi @seadowg,

I already can tell you that there will be no support for passing the current time to the decode method. This would break the purpose of JWT itself.

I would make use of the exp and nbf claims in your scenario to simplify my tests.

Have a look at our tests for the exp claim (https://github.com/jwt/ruby-jwt/blob/master/spec/jwt/verify_spec.rb#L46-L80). This should make it possible for you to create JWTs for your test via a JWT factory class. IMO there's no need to time travel in tests with JWT.

You may one or two sample tests with the issue. We can figure out what's the best way in your scenario.

[seadowg]

Hey @excpt! Thanks for the reply and the tips around tests JWT.

I'm not sure I fully understand how adding the ability to pass the current time would break it. Are you meaning that would increase the chance for "human error" i.e. someone passes an incorrect time object in production code? If that's the case I completely understand. If passing the current time is optional however this might not be as risky. This could also make the library viable for people using non system time sources (external clock services to account for hardware drift etc). Of course you might not want to introduce any of the complexity/risk but just throwing my hat in.