Closed tabarra closed 4 years ago
@tabarra thanks for the suggestion.
Is it safe to say you want to be able to identify these four specific errors?
printf: ['too much time has elapsed since the last End-User authentication, max_age %i, auth_time: %i, now %i', maxAge, payload.auth_time, timestamp - this[CLOCK_TOLERANCE]],
printf: ['JWT issued too far in the past, now %i, iat %i', timestamp, payload.iat],
printf: ['JWT not active yet, now %i, nbf %i', timestamp + this[CLOCK_TOLERANCE], payload.nbf],
printf: ['JWT expired, now %i, exp %i', timestamp - this[CLOCK_TOLERANCE], payload.exp],
Would be awesome to have code for all errors, since I would also like to handle timeout errors more gracefully, but those are more "edge cases".
Having an error code (or some other identifier) for those 4 would certainly help me out a lot!
And as always, thanks for the responsiveness @panva!
Worked perfectly!
Once again, thanks for being so open to small tweaks!
Is your feature request related to a problem? Please describe. I would like to know when an code exchange error could be solved by synchronizing the host clock (90% of the problems my users have), but checking the error for
error.message.startsWith('JWT expired, now')
is a bit too hacky.Describe the solution you'd like Add the property
code
for the RPerror class with a small, likely stable, string indicating the issue.Examples:
jwt_nbf_invalid
,jwt_expired
.Alternatively, you could add the an
CLOCK_TOLERANCE
property to any error that is related to this variable.Describe alternatives you've considered
error.jwt
and re-checking those cases is redundant;Additional context My open source project is very very often deployed on windows servers right after deployment, with some atrocious clocks.