decentraland / world-storage-service / 32378180676

99%

push

github

fix(auth): upgrade @dcl/crypto-middleware to 6 (#116)

* fix(auth): upgrade @dcl/crypto-middleware to 6

@dcl/crypto-middleware 6 changes the signed payload wire format: method,
path and timestamp are lowercased individually and the metadata is joined
verbatim, instead of lowercasing the whole joined string. Metadata casing
is now covered by the signature.

No source changes were needed. The middleware hands handlers the metadata
with its original casing both before and after, so the scene gate in
routes.ts and every authMetadata read behave identically.

Bump decentraland-crypto-fetch to 3, the client half of the same format
change. It signs every integration request, so without it the suite would
sign the old payload and get a 401 from a correctly-working server.

Update test/integration/auth/canonical-signer.spec.ts:

- Metadata re-cased after signing is now refused by signature
  verification (401 Invalid signature) instead of the canonical-value
  guard (400 Invalid chain metadata). Same request, same refusal, one
  layer earlier.
- A whitespace-padded scene signer is no longer refused at all. Version 6
  drops the canonical-value guard, and binding the metadata bytes to the
  signature does not cover a value that was already padded when signed,
  so it passes the strict `!==` in routes.ts and is served as an ordinary
  user-signed request. The tests now pin that behaviour and flag the gap.

* test(auth): state why the padded-signer change is not an escalation

The comment framed the dropped canonical-value guard as a reopened gap,
which reads as a call to restore it. Producing a padded signer requires
holding the identity key, and a key holder can already omit the field
entirely — 5.1.0 allowed that too, since its guard only inspected string
values. The guard covered one spelling of a self-declared label while
leaving omission open.

Records the reasoning next to the cases that pin the behaviour.

* refactor(auth): use rejectIfSigner from crypto... (continued)

424 of 438 branches covered (96.8%)

Branch coverage included in aggregate %.

1 of 1 new or added line in 1 file covered. (100.0%)

1145 of 1152 relevant lines covered (99.39%)

71.32 hits per line