Currently, the leeway property of Datetime claims is set after the instance creation, calling the relative setter method. This could cause validation errors inside the validateCreate method of the IssuedAt class, in the case where an instance gets created using a value from an existing token, due to the leeway not being considered.
This has caused some problems on one of our services that was running on a pool of different hosts which happened to have their system clocks out of sync. We solved the issue by fixing our NTP configurations, but we'd appreciate the leeway property to be correctly handled by the library.
The problem seems to be also mentioned here.
We really appreciate your effort with this project and we hope you find this helpful. I'm always available if you need me to further expand on this.
Currently, the
leewayproperty of Datetime claims is set after the instance creation, calling the relative setter method. This could cause validation errors inside thevalidateCreatemethod of theIssuedAtclass, in the case where an instance gets created using a value from an existing token, due to the leeway not being considered.This has caused some problems on one of our services that was running on a pool of different hosts which happened to have their system clocks out of sync. We solved the issue by fixing our NTP configurations, but we'd appreciate the
leewayproperty to be correctly handled by the library. The problem seems to be also mentioned here.We really appreciate your effort with this project and we hope you find this helpful. I'm always available if you need me to further expand on this.
Have a nice weekend!