add max_clock_skew to HTTPMessageVerifier #11
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a
max_clock_skew
attribute toHTTPMessageVerifier
so the verification of timestamps is more tolerant to deltas between clocks of the signer and verifier, which are common whenIn #10 (comment), we suggested a 30s default. However, in my experience, this is much higher than common clock deltas, which should usually be less than a few hundred milliseconds in healthy systems. I suggest starting with a 5s default, which should be good enough for most use cases. It will be easy to raise the default if needed in the future; however, lowering it could cause damage to production systems that may have been relying on it.
The tolerance applies to all timestamp verification: creation, expiration, and max age. The original issue I reported only mentioned problems with verifying creation time, but I tried to keep it simple and have all time checks behave the same instead of making special cases.
@kislyuk, let me know if you feel strongly about any of those points, and I'll make the change.
Fixes #10