-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Pinpoint requests fail if client's clock is not accurate with error "Signature expired" or "Signature not yet current" #9281
Comments
Closing this as a duplicate of #6494, which has been fixed by aws-amplify/amplify-cli#9158 |
Did you actually test @chrisbonifacio - this is not duplicate. I can still repro this one even after verifying that aws-amplify/amplify-cli#9158 fixes #6494 |
Hey @hisham 👋 My apologies. Maybe I'm misunderstanding how to test this. Here's a screenshot showing my local machine's time, which I moved ahead manually. At the bottom of the screenshot is my remote machine's clock which was the correct time. When I call const event = await Analytics.record({
name: "testingClockDrift",
}); The response I get is a status code of 202 and "Message Accepted", and I can see the timestamp of the event is also a minute ahead, same time as my system clock. Payload Response Is there a different way I can change the time to better reproduce this? |
Ah! Turns out I didn't actually save the changes I made to the time on my local machine, didn't think I had to hit the lock icon to do that 🤦 "Click the lock to prevent further changes" didn't help, sounds like I already made changes 😓 But, I totally see what you mean! Now I get the errors just as you described them. Thank you for making me double check myself on this one! Labeling as a bug for the team and will see if I can get an update for you 😄 |
Any movement/change on this? We hit it with a customer who's phone's clock was 10-15 mins in the future (no, I dont know why...) We are using it for storage, which is where we are seeing the issues, AFAIK. |
Confirmed this is still an issue and even elevations in auth/unauth role's permissions policies doesn't change the outcome. It does require some manual changes to the local "Date and Time" to reproduce as @chrisbonifacio stated above. Events do NOT record in Pinpoint when this occurs. Screenshots of errors for context: @nicwise and @hisham, I will review this further with our team internally and provide an update soon regarding it's review as a known bug. Appreciate your patience with this! |
Hi, is there any update on this? |
@KevinToala, we don't have any updates on this at this point. However, there have been some recent issues opened related to clock skew that are currently being reviewed. If there are any relevant updates I can provide, I'll be sure to comment here! |
I'm not sure the best place to leave this, as it is not Pinpoint we are using. The related issues seem to be closed. I can re open a new ticket if need be. I have an Amplify project using GraphQL and a public identity pool for auth. We have this error and it causes the api to fire off without stopping. It seems to make its way through all the Clock Drift code, but still reruns infinitely. Our error rate is often 90 percent 4xx errors, as a single client can fire off 50,000+ times. (Not joking, we have seen it do tens of thousands of requests from a single user). All of it is tied to this clock issue, as the only way to replicate it is by flipping the time back and forth. So far our only possible solution is downgrading to 5.3.3 which doesn't seem to infinite loop, but also does not retry getting a valid token. I got this version from a comment left by @hisham on this issue:
|
Before opening, please confirm:
JavaScript Framework
Angular
Amplify APIs
Analytics
Amplify Categories
auth, storage, function, api, analytics
Environment information
Describe the bug
If client's clock is ahead or behind, pinpoint network events will fail. It will fail with "Signature expired" if clock is behind and "Signature not yet current" if clock is ahead.
It seems this was reported in #3699 but not resolved.
Expected behavior
Network events should work regardless.
Reproduction steps
Set your clock ahead or behind and do an Analytics.record.
Code Snippet
// Put your code below this line.
Log output
aws-exports.js
No response
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response
The text was updated successfully, but these errors were encountered: