From ef55a918d3f2dacec3f8f15ee75c807c3182dda0 Mon Sep 17 00:00:00 2001 From: tiennm99 Date: Thu, 9 Apr 2026 09:37:19 +0700 Subject: [PATCH] =?UTF-8?q?fix:=20correct=20HMAC=20feature=20decision=20?= =?UTF-8?q?=E2=80=94=20clarify=20Statuspage=20platform=20limitation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/feature-decisions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/feature-decisions.md b/docs/feature-decisions.md index 7fef716..67ba4a7 100644 --- a/docs/feature-decisions.md +++ b/docs/feature-decisions.md @@ -50,7 +50,7 @@ Suggested features evaluated during code review (April 2026). Each was declined **Idea**: Verify Statuspage webhook payloads using HMAC signatures as a second auth layer beyond URL secret. -**Decision**: Skip. Atlassian Statuspage does not provide HMAC signature headers for webhook deliveries. The URL secret is the only auth mechanism they support. If they add signature support in the future, this should be revisited. +**Decision**: Skip. Atlassian Statuspage's public subscriber webhooks (the "Subscribe to Updates" → "Webhook" flow) do not provide HMAC signature headers. The only verification mechanism available is embedding a secret in the URL path, which this project already implements with timing-safe comparison. This is a platform limitation, not a design choice — if Atlassian adds signature support in the future (tracked as BCLOUD-14683), this should be revisited. ### 9. Proactive Rate Limit Tracking