Skip to content

Conversation

ogenodisho
Copy link

@ogenodisho ogenodisho commented Sep 4, 2025

Motivation

This is to address #93

The motivation is described in detail in the issue.

Solution

Introduce a timedelta parameter in the Webhook init function which specifies the tolerance.

Consumers may leave this blank and it will default to 5 minutes, or provide timedelta.max to essentially bypass tolerance checking.

This change is backwards compatible.

@ogenodisho ogenodisho requested a review from a team as a code owner September 4, 2025 12:50
@ogenodisho ogenodisho changed the title Update python sdk to allow a configurable webhook tolerance. [Python] Make the webhook tolerance configurable. Sep 4, 2025

def __init__(self, whsecret: t.Union[str, bytes]):
def __init__(self, whsecret: t.Union[str, bytes], whtolerance: timedelta = timedelta(minutes=5)):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a better approach would be adding the VerifyIgnoringTimestamp method, like we have in Go, as it was discussed in #93

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concern with this is that it might make it 'easy' to use potentially insecure tolerances. With a separate method it's clear that the security implications are different.

Copy link
Author

@ogenodisho ogenodisho Sep 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @svix-lucho, thanks for the review.

I did see that part in the related issue about verifying the webhook while ignoring the timestamp. However, my reasoning for doing it this way is that I think it's actually safer (and more flexible) than allowing consumers to disable the timestamp verification entirely.

If a consumer disables it entirely, they're much more susceptible to replay attacks. However, if the tolerance is configurable, they have the flexibility of tuning the tolerance to suit their use cases, while still being protected against potential replay attacks to a certain degree.

In regards to your second message, I wouldn't be opposed to introducing a verify_using_custom_tolerance method instead.

Please let me know your thoughts.

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