Fix critical webhook signature case bug; add correlationId + AR type registration

Strike sends X-Webhook-Signature in UPPERCASE hex. OpenSSL::HMAC.
hexdigest always returns lowercase, and valid_signature? compared them
case-sensitively via secure_compare — every genuine Strike webhook was
being silently rejected as an invalid signature. Confirmed live: executed
a real Lightning payment (payment-quotes/lightning + PATCH .../execute),
received a real payment.updated webhook, and recomputing the HMAC over
the captured payload/secret matched case-insensitively but not
case-sensitively — proving the algorithm/secret/body were already
correct and this was purely a case-comparison bug. Their own reference
docs (docs.strike.me/webhooks/signature-verification) don't mention the
case difference. Regression test added using the real captured signature,
upcased.

Also, both found via that same live test:
- Invoices::Invoice didn't declare correlationId, raising
  ActiveModel::UnknownAttributeError the moment a real one (which
  CreateInvoice always sends) round-tripped through a live response —
  no existing spec fixture's stubbed body had included it.
- BtcAttributeType was only registered with ActiveModel::Type, not
  ActiveRecord::Type (a separate registry) — an `attribute :x,
  :strike_btc` declaration on an ActiveRecord model raised "Unknown
  type" without this. Guarded behind defined?(ActiveRecord::Type) since
  this gem only depends on active_model.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
bterkuileandClaude Sonnet 5 committed 2026-09-22 19:13:03 -05:00
1 parent ae9ab1564e
commit ac2558f5ce
5 files changed
+59 -17

No files matched your search

+9
View File
@@ -12,6 +12,15 @@ module StrikeMe
attribute :issuerId
attribute :receiverId
attribute :payerId
# Only present on the #create response, echoing back whatever
# Invoices#create sent as correlationId (Strike's own docs list
# it as request-optional/response-present) — missing here meant
# ActiveModel::UnknownAttributeError the first time a real
# correlation_id round-tripped through a live Strike account (no
# existing spec fixture's stubbed response body included it, so
# this went uncaught until now). end_with?('Id') below already
# picks this up automatically, same as every other *Id field.
attribute :correlationId
alias_attribute :id, :invoiceId
attribute_names.select { _1.end_with? 'Id' }.each do |snake_name|
+12 -1
View File
@@ -22,7 +22,18 @@ module StrikeMe
return false if signature.blank? || raw_body.blank?
expected = OpenSSL::HMAC.hexdigest('SHA256', secret, raw_body)
secure_compare(expected, signature)
# Strike sends X-Webhook-Signature in UPPERCASE hex — confirmed
# live against a real webhook delivery (payment.updated, a real
# executed Lightning send) 2026-09-22. OpenSSL::HMAC.hexdigest
# always returns lowercase. Without downcasing both sides here,
# secure_compare's case-sensitive byte comparison rejected every
# genuine Strike webhook as an invalid signature — silently: a
# rejected webhook looks identical to an actual forgery attempt
# from the outside, so this would have broken settlement in
# production with no visible error at all. Their own docs'
# reference implementation (docs.strike.me/webhooks/
# signature-verification) doesn't mention this case difference.
secure_compare(expected.downcase, signature.downcase)
end
# ActiveSupport::SecurityUtils.secure_compare raises on a length