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

Fix timezone comparison issue #290

Merged
merged 2 commits into from
Apr 15, 2020
Merged

Fix timezone comparison issue #290

merged 2 commits into from
Apr 15, 2020

Conversation

irhkang
Copy link
Contributor

@irhkang irhkang commented Apr 15, 2020

When ENABLE_SAVE_LAST_DECRYPTION_TIME is enabled and the eye icon is clicked, confidant returns a 5xx because the last_rotation_date field of the response is trying to compare a tz unaware timestamp with a tz aware timestamp. Essentially what was happening was:

# Assume someone just rotated a credential
c = Credential.get(123)
c.last_rotation_date = datetime.now() # no tzinfo
c.save()   # Pynamo will add tzinfo=UTC to last_rotation_date
...
# One day later
...
c = Credential.get(123)
c.last_decrypted_date = datetime.now() # no tzinfo
c.save()  # Pynamo will add tzinfo=UTC to last_decrypted_date
c.next_rotation_date # uses the unsaved object (`c`) and compares `last_decrypted_date` (no tzinfo with last_rotation_date, which has the tzinfo because pynamo added it

Essentially, had we refetched the object (did another Credential.get(123)), we wouldn't have this problem but we were using the unsaved object.

Instead of using datetime.now() we create a new method that automatically adds a tzinfo.

(Side note: Why python's datetime.utcnow() doesn't have a tzinfo in it is beyond me)

@irhkang irhkang merged commit 836de2d into master Apr 15, 2020
@irhkang irhkang deleted the I-fix branch April 15, 2020 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants