Challenge 2: Verify a Webhook Signature — Possible Solution
====================================================================

STEP-BY-STEP VERIFICATION
------------------------------
1. Read the RAW request body exactly as it arrived, byte for byte —
   not a re-serialized or reformatted version of it. HMAC is
   sensitive to even a single whitespace or character difference, so
   the exact raw bytes matter.

2. Extract the signature value from the X-Signature header (e.g. the
   "v1=..." portion).

3. Using the SAME shared secret that was agreed upon when the webhook
   was originally registered with the provider, compute an HMAC
   (e.g. HMAC-SHA256) over the raw request body from step 1.

4. Compare the signature YOU just computed against the signature
   value extracted from the header in step 2.

5. If they match exactly, the payload is trusted as genuinely coming
   from the provider and unaltered in transit — proceed to process
   the event normally. If they DON'T match, reject the request
   (respond with an error status, and do NOT process the event) —
   it may be forged or corrupted.

WHY THIS WORKS AS AN ANSWER
------------------------------
The core idea is that ONLY someone who knows the shared secret could
have produced a signature that matches the body — since an attacker
sending a fake request wouldn't know that secret, they couldn't
produce a signature that would pass step 4's comparison, even if
they perfectly copied the JSON shape of a real event. This is exactly
why HMAC verification is the standard defense against forged webhook
requests: it doesn't rely on obscurity or trusting the network, it
relies on a secret only the real provider (and you) actually possess.