Skip to content

feat(webhook): verify native Asana webhook signatures (X-Hook-Signature) - #54697

Open
mguttmann wants to merge 1 commit into
NousResearch:mainfrom
mguttmann:feat/asana-webhook-signature
Open

feat(webhook): verify native Asana webhook signatures (X-Hook-Signature)#54697
mguttmann wants to merge 1 commit into
NousResearch:mainfrom
mguttmann:feat/asana-webhook-signature

Conversation

@mguttmann

Copy link
Copy Markdown
Contributor

Closes #54693.

What

Add native verification of Asana's X-Hook-Signature (hex HMAC-SHA256 over the raw body, keyed by the handshake secret) to the webhook adapter, with a constant-time compare.

Why

The adapter recognised GitLab and a generic HMAC header but not Asana's scheme, so Asana deliveries couldn't be authenticated natively — integrators had to fall back to a generic header or disable verification.

Why this is better

  • First-class Asana webhook support out of the box.
  • Constant-time compare (hmac.compare_digest) — no timing side channel.
  • Purely additive; sits alongside the existing GitLab/generic/Svix branches and changes none of them.

Test

  • python -m py_compile gateway/platforms/webhook.py passes.
  • Manual: an Asana webhook delivery with a valid X-Hook-Signature authenticates; an invalid one is rejected.

The generic webhook adapter recognised GitLab and a generic HMAC header, but not
Asana's native signature scheme. Asana signs each delivery with
`X-Hook-Signature` = hex HMAC-SHA256 over the raw request body, using the secret
exchanged during the initial `X-Hook-Secret` handshake.

Add explicit verification for that header so Asana webhooks can be authenticated
natively (constant-time compare), instead of forcing integrators to fall back to a
generic header or disable signature verification entirely.
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/gateway Gateway runner, session dispatch, delivery platform/webhook Webhook / API server sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages labels Jun 29, 2026
@teknium1

Copy link
Copy Markdown
Contributor

Thanks for adding the provider-specific comparison; the HMAC calculation itself matches the stated wire format.

Problems

  • This cannot establish a usable Asana webhook yet. Asana requires the initial POST's X-Hook-Secret to be echoed with 200/204; current request handling instead requires an already-configured secret and rejects an unsigned handshake at gateway/platforms/webhook.py:524-540. The PR only adds a later signature branch, so normal Asana setup will fail before it can be used.
  • The PR changes gateway/platforms/webhook.py only. Please add coverage beside the existing signature tests in tests/gateway/test_webhook_adapter.py:129, including the required handshake plus valid and tampered Asana signatures.

Suggested changes

  • Add an explicit route-scoped Asana handshake and a safe secret storage/configuration lifecycle, then document that setup in website/docs/user-guide/messaging/webhooks.md:452-465.

Automated hermes-sweeper review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/gateway Gateway runner, session dispatch, delivery P3 Low — cosmetic, nice to have platform/webhook Webhook / API server sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages sweeper:risk-security-boundary Sweeper risk: may affect sandboxing, auth, credentials, or sensitive data type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Webhook adapter has no native Asana signature verification (X-Hook-Signature)

3 participants