PyJWT currently hardcodes calls to datetime.now() and uses the result to validate timestamp-related claims (such as iat, nbf and exp).
This prevents to validate the claims against a user-provided timestamp, preventing deterministic unit testing of code that calls into PyJWT and possibly some more exotic use cases. My unit tests are now dependent on the current system time and I need to mock it to make them deterministic and repeatable.
I propose to introduce a new parameter to the .decode() method or possibly in its options dict, current_time: typing.Optional[datetime.datetime], defaults to None. When it is None the current logic applies (and this makes it 100% backwards compatible), when it is not None PyJWT will use the provided datetime instead of calling into datetime.now().
I made my example on PyJWT.decode() but this should obviously extended to all public-facing methods that end reading the current system time from datetime or time or anything else.
PyJWT currently hardcodes calls to
datetime.now()
and uses the result to validate timestamp-related claims (such asiat
,nbf
andexp
).This prevents to validate the claims against a user-provided timestamp, preventing deterministic unit testing of code that calls into PyJWT and possibly some more exotic use cases. My unit tests are now dependent on the current system time and I need to mock it to make them deterministic and repeatable.
I propose to introduce a new parameter to the
.decode()
method or possibly in itsoptions
dict,current_time: typing.Optional[datetime.datetime]
, defaults toNone
. When it isNone
the current logic applies (and this makes it 100% backwards compatible), when it is notNone
PyJWT will use the provided datetime instead of calling intodatetime.now()
.I made my example on
PyJWT.decode()
but this should obviously extended to all public-facing methods that end reading the current system time fromdatetime
ortime
or anything else.