fix(gitlab): re-push webhook tokens on integration (re)install#117801
Merged
Conversation
The GitLab webhook_secret is derived deterministically from the OAuth app's client_id (sha1(hostname + client_id)) and stored on the shared Integration.metadata. When a customer reinstalls against a new OAuth app the client_id changes, so the secret rotates and metadata is overwritten, but the tokens already registered on existing GitLab project hooks are never re-pushed. Inbound webhooks then keep sending the old token and fail the constant-time secret check in webhooks.py with a 409. Override post_install in GitlabIntegrationProvider to schedule a webhook refresh via the existing repository_service.schedule_update_gitlab_project_webhooks machinery. Because the secret lives on the shared Integration, refresh every organization that has the integration installed, not just the one running the (re)install. Fresh installs have no repos yet, so they are a harmless no-op. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
github-actions
Bot
added
the
Scope: Backend
Member
|
@GabeVillalobos do you have any context on this? would you be able to review it? |
Member
|
@billyvg Yep, this change makes sense. Seems like we just missed the update case somehow, so I wonder how long this has actually been broken. |
Member
|
SFO is out tomorrow, gonna wait until Monday to merge |
GabeVillalobos
added
the
Trigger: Revert
Contributor
|
PR reverted: 1f832b5 |
Member
|
This looks like it conflicts with #112699, so I'm reverting in the meantime. We need to unify our webhook update and creation logic before reattempting it I think. |
sehr-m
pushed a commit
that referenced
this pull request
Jun 23, 2026
This PR addresses the point "0." in [this comment](#93724 (comment)). It was authored by Claude and reviewed by me. I'm confident enough to submit it. Todo: - [ ] Test end-to-end in dev. The GitLab webhook_secret is derived deterministically from the OAuth app's client_id (sha1(hostname + client_id)) and stored on the shared Integration.metadata. When a customer reinstalls against a new OAuth app the client_id changes, so the secret rotates and metadata is overwritten, but the tokens already registered on existing GitLab project hooks are never re-pushed. Inbound webhooks then keep sending the old token and fail the constant-time secret check in webhooks.py with a 409. Override post_install in GitlabIntegrationProvider to schedule a webhook refresh via the existing repository_service.schedule_update_gitlab_project_webhooks machinery. Because the secret lives on the shared Integration, refresh every organization that has the integration installed, not just the one running the (re)install. Fresh installs have no repos yet, so they are a harmless no-op. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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 addresses the point "0." in this comment.
It was authored by Claude and reviewed by me. I'm confident enough to submit it.
Todo:
The GitLab webhook_secret is derived deterministically from the OAuth app's client_id (sha1(hostname + client_id)) and stored on the shared Integration.metadata. When a customer reinstalls against a new OAuth app the client_id changes, so the secret rotates and metadata is overwritten, but the tokens already registered on existing GitLab project hooks are never re-pushed. Inbound webhooks then keep sending the old token and fail the constant-time secret check in webhooks.py with a 409.
Override post_install in GitlabIntegrationProvider to schedule a webhook refresh via the existing repository_service.schedule_update_gitlab_project_webhooks machinery. Because the secret lives on the shared Integration, refresh every organization that has the integration installed, not just the one running the (re)install. Fresh installs have no repos yet, so they are a harmless no-op.