Hello @sviluppomania,
Thank you for reaching out and for highlighting this!
I’d appreciate a bit more context so I can better understand the issue and also what you are trying to achieve:
- You mentioned a bug in the JWT implementation related to solar time and daylight saving time. As far as our implementation goes, this should not be the case—our plugin relies on synchronized system time, and time zones or DST shifts should not affect the token validation process. The only requirement is that the server time and the device generating the 2FA code are in sync. Maybe you can elaborate a bit more on the problem observed with a few more examples?
- You also suggested adding a leeway of 1 or 2 hours to the JWT validity. Could you elaborate on why this is needed in your specific case? Is the token being rejected due to time mismatch, or are users consistently experiencing failed logins due to timing issues? Again, the more details, the better.
- If possible, please share more details about your setup, use case, or the symptoms you’ve observed—whether this affects all users, specific roles, or devices. Any logs, screenshots, or steps to reproduce would also be helpful.
Looking forward to your reply so we can look deeper into this.
Many thanks!
Hi @lucianwpwhite ,
thank you for your reply.
I answer to your question:
– I checked the server time zone/system time and it is in sync with the device. See here Time ( https://www.sviluppomania.com/it/time/ ) (this is a test page that prints the current date and time)
– We have increased the token validity because we have received an expired token
– See below
{ "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6IjE3MjY0MTYzODEifQ.eyJpZCI6ImdkbXo0cXVucjBjdHJuMmNrbGJnYjBidjlrdzJxbXVoeDlsbmk1bnIiLCJqdGkiOiJnZG16NHF1bnIwY3RybjJja2xiZ2IwYnY5a3cycW11aHg5bG5pNW5yIiwiaXNzIjoiaHR0cHM6XC9cL3d3dy5zdmlsdXBwb21hbmlhLmNvbVwvaXQiLCJhdWQiOiJWc0FXU1Z0bVRwNWIzek5pdzFvU0pkcWZYT1BqTUNlRmFOVGxUZHlkIiwic3ViIjoiODkiLCJleHAiOjE3NDUwODI1NjUsImlhdCI6MTc0NTA3ODk2NSwidG9rZW5fdHlwZSI6ImJlYXJlciIsInNjb3BlIjoiYmFzaWMiLCJkYXRhIjp7InVzZXIiOnsiaWQiOiI4OSJ9fX0.w_cT3j3dxYI0a4Z-YrqOErje9557d_Gcrh5Rmlhb3e0", "expires_in": 3600, "token_type": "bearer", "scope": "basic", "refresh_token": "jxdr5dnsqz2p7tsmepi0z5cxhbkqxap6ostzb5t8"}
Here you can find the response using this token:
{ "code": "jwt_auth_invalid_token", "message": "Cannot handle token prior to 2025-04-19T16:09:25+0000", "data": { "status": 403 }}
I can tell you that this token was generated at the time of expiration. For this reason we have decided to increase the token validity from 3600 to 7200 (in order to have a token with 1h of validity).
Thank you
Hello again @sviluppomania,
Thank you for your follow-up and the detailed information!
After reviewing this further and discussing with the developers, I’d like to clarify that the specific JWT handling code you referenced (vendor/firebase/php-jwt/src/JWT.php) is typically used in the Premium edition of the plugin, however, can you maybe specify the exact location in the code where you are using that? That should help a lot as this the first time we are dealing with such specific and targeted questions.
As a general rule, we’re unable to provide support for custom implementations or modifications made to the plugin. These can often introduce conflicts or unexpected behavior, and fall outside the scope of what we can assist with.
However, if you can provide the full error stack trace or any other context from the logs, coming from our plugin (on top of the above shared), as well as the exact location where it’s used, we’ll do our best to point you in the right direction.
Thanks again for your cooperation, and we’ll wait to hear from you.