decentraland / social-service-ea / 32525434727

91%

push

github

chore: take the crypto libraries that bind signed-fetch metadata to the signature (#492)

Upgrades @dcl/crypto-middleware to ^6.2.0 and decentraland-crypto-fetch to
^3.0.0. Both now build the signed payload as

  [method.toLowerCase(), path.toLowerCase(), timestamp, metadata].join(':')

rather than folding the whole joined string. Folding left the metadata's casing
outside the signature while services read the unfolded x-identity-metadata
header, so a property name or value re-spelled after signing kept a valid
signature and read as absent to a service comparing it for equality. Joining the
metadata verbatim brings every field under the signature, consumer-defined ones
included. Signer and verifier build the same bytes, so they move together.

Replaces isSceneSigner, which folded the value before comparing, with
rejectIfSigner('decentraland-kernel-scene'). Under 6.x nothing may be normalized
on the way in — what reaches a handler is exactly what was signed — so the gate
refuses a non-canonical signer instead of rewriting it, reads the field as an own
property, and still passes a request that declares no signer at all. It is built
once at module load, so a non-canonical argument is a startup failure rather than
a gate that quietly never fires. It stays wired through metadataValidator, which
runs before signature verification, so rejections are 400s costing no catalyst
round-trip; the re-cased-value case now answers "Invalid metadata content" from
this gate instead of "Invalid chain metadata" from a library guard 6.x removed.

Inert to deploy in any order. Every first-party caller sends {} as its metadata,
which folds to itself, so both formats produce identical payloads for it. No
canonicalMetadataKeys fallback is wired: the only uppercase-bearing metadata in
the ecosystem is the SDK signedFetch metadata a scene attaches, and those
requests are refused here either way.

core-js-pure leaves the lockfile with crypto-fetch 3.0.0, which no longer depends
on it.

2591 of 2989 branches covered (86.68%)

Branch coverage included in aggregate %.

4 of 4 new or added lines in 3 files covered. (100.0%)

6241 of 6693 relevant lines covered (93.25%)

92.95 hits per line