ticarpi
commented
3 years ago Thanks so much for taking the time to submit this PR. I haven't implemented this to avoid adding in new bugs to the code, as the current submission would cause errors if additional alternative exp formats were used. I aim to cover all eventualities within the JWT standards (RFC7519 etc.), or when there is fairly common alternative usage (e.g. misconfigurations by common libraries).
From the RFC (bold formatting for emphasis):
4.1.4. "exp" (Expiration Time) Claim
The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
As far as I am aware the use of alternative formats for 'exp' claims is rare, but I will tweak this PR and include it if sufficient need arises.
Hi, the code here is intended to solve a small bug that your application has when a jwt token has an exp parameter with a value that can not be converted to int as follows: 2021-02-15T11:37:25.067Z
My solution aims to avoid this kind of cases where the conversion to integer fails.