decentraland / decentraland-gatsby / 32888147950

58%

push

github

fix(deps): upgrade @dcl/crypto-middleware to 6.3.0 (#1330)

6.3.0 adds a `hasFoldedVariant` guard to `canonicalField` and
`requireCanonicalField`, which `rejectIfSigner` and `requireSigner` are
built on. Until now those predicates read the exact key, so metadata
delivering `{"Signer":"decentraland-kernel-scene"}` presented no `signer`
field at all and every predicate treated it as absent.

`verifySigner`, the default `metadataValidator` behind `withAuth` and
`withAuthOptional`, is built on `rejectIfSigner('decentraland-kernel-scene')`
— so it answered "allowed" for metadata that visibly names the signer it
exists to refuse. This was reachable on the strict current-format path:
re-spelling the key changes the signed bytes, so the request has to be
signed that way, which a scene-driven client can simply do. The signature
is genuinely valid and nothing else refuses it. Verified against 6.2.0,
`withAuth` resolved such a request with
`metadata: {"Signer":"decentraland-kernel-scene"}` — a scene-signed
request served as a directly user-signed one.

Under 6.3.0 a key that case-folds to the declared field without being
spelled exactly that is a rejection rather than an absence. Nothing is
folded: the value is refused, never rewritten.

The pin stays exact because `src/utils/auth/payload.ts` still deep-imports
`@dcl/crypto-middleware/dist/verify` for `createPayload`; that path is
confirmed present in 6.3.0. 6.3.0 carries the same dependencies as 6.2.0,
so the lockfile change is limited to the four lines that name the version.

Covers the gap through gatsby's own auth surface in both the required and
the optional route helper. Both new tests fail against 6.2.0 and pass
against 6.3.0.

531 of 1116 branches covered (47.58%)

Branch coverage included in aggregate %.

1317 of 2057 relevant lines covered (64.03%)

12.7 hits per line