Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception: Cannot handle token prior to [timestamp] #56

Closed
SimonEast opened this issue Jan 15, 2016 · 16 comments
Closed

Exception: Cannot handle token prior to [timestamp] #56

SimonEast opened this issue Jan 15, 2016 · 16 comments

Comments

@SimonEast
Copy link

As I mentioned in this issue (over in PHP-JWT), I'm getting this exception triggered a lot when calling $auth0->getUser(). It first happened on my development machine and now on my web host:

Cannot handle token prior to 2016-01-15T14:44:28+1100

It appears to occur when the server's clock is a few seconds behind Auth0's. I resynced my local dev machine's clock and the message went away. I can't do that on a shared web hosting server though. :-(

My thoughts are that the time check should not be so strict that it requires an up-to-the-second time-synchronization.

Simon.

@SimonEast
Copy link
Author

My ugly hack/workaround for now was to comment out the exception in 2 places in /vendor/firebase/php-jwt/Authentication/JWT.php:

//---------------------------------------
// Temporarily commenting out to fix bug
//---------------------------------------
// throw new BeforeValidException(
//     'Cannot handle token prior to ' . date(DateTime::ISO8601, $payload->nbf)
// );
//---------------------------------------   

I'm not sure if that reduces the security significantly or anything? I suspect not by much.

@glena
Copy link
Contributor

glena commented Jan 15, 2016

Try setting the leeway in the php-jwt.

Somewhere in your project before the auth0 sdk is initialized add this line:

\Firebase\JWT\JWT::$leeway = X;

this will let you move the time window X seconds, ceck if you are ahead or behind and play with it until you find a confortable value.

@glena
Copy link
Contributor

glena commented Jan 18, 2016

@SimonEast did it work?

@SimonEast
Copy link
Author

OK, awesome. That's the kinda thing I was looking for. Haven't tried it yet but hope to do so in the next 1-2 weeks and will try post back how it goes.

@glena
Copy link
Contributor

glena commented Jan 24, 2016

sure, I will close the issue for now but feel free to open a new one (or just ping me here)

@glena glena closed this as completed Jan 24, 2016
@SeanZicari
Copy link
Contributor

@SimonEast Did the leeway setting work for you? What setting did you settle on?

@SimonEast
Copy link
Author

@SeanZicari I actually can't remember what I did with it 12 months ago, I'm sorry. I'd have to dig through my source code, which I may not get time to do very soon due to life circumstances. I apologize.

@glena
Copy link
Contributor

glena commented Feb 20, 2017

@SeanZicari the leeway should do the trick, anyway if it is posible check that your server's timezone is well configured and that it is sincronized with an NTP server so it keeps up to date.

Also, can you check what is the difference between the server time and the current time?

@SeanZicari
Copy link
Contributor

@glena Thanks! I increased the leeway to 120 seconds. Is that excessive? It did seem to resolve the issue.

@glena
Copy link
Contributor

glena commented Feb 23, 2017

@SeanZicari it is not a good idea because you are opening the expiration window. It is always better to try to keep the server time in sync to avoid future issues.

@SeanZicari
Copy link
Contributor

@glena That makes sense. The issue I was having seemed to be related to one individual auth0 account that was causing that error to be thrown when trying to log in as them. I don't know enough about what's going on behind the scenes to know how else to fix it.

@glena
Copy link
Contributor

glena commented Feb 23, 2017

if you have ssh access to the server, you can check the time of it (if it is linux by running date) and check if it is correct (time and timezone). Probably it is some minutes off.

If that is the case, I would recommend to configure it to be in sync with an NTP service or if it is already configured you will need to troubleshoot why it is not working.

@SeanZicari
Copy link
Contributor

SeanZicari commented Feb 24, 2017 via email

@sohailrajdev97
Copy link

@glena Thanks. This solved the problem.

@fsiatama
Copy link

ntpdate -q 0.rhel.pool.ntp.org
chkconfig ntpdate on
service ntpdate start

duan-li added a commit to duan-li/auth0-php-web-app that referenced this issue Feb 8, 2019
Cannot handle token prior
auth0/auth0-PHP#56
@github-actions
Copy link
Contributor

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants