decentraland / notifications-workers / 32870727277

80%

main: 80%

push

github

fix(auth): accept the pre-6.0.0 signed payload (#185)

* fix(auth): accept the pre-6.0.0 signed payload

Upgrading to crypto-middleware 6 made this service verify the metadata
bytes as delivered. Every current caller still signs the folded payload --
the whole joined string lowercased -- while sending the metadata header
verbatim, so the two disagree for any metadata carrying uppercase.

`PUT /notifications/read` carries `notificationIds`, which means
decentraland-dapps (builder, marketplace, profile, account) and
godot-explorer get a 401 on every attempt to mark a notification read
once this deploys. The suite did not catch it because the shared
`getAuthHeaders` helper already signs the 6.x payload.

Declaring `canonicalMetadataKeys` opts the routes into verifying that
older format as a fallback, tried only after the current one fails.

Only `signer` is declared. No handler in this service reads
`authMetadata` at all -- `readNotificationsHandler` takes the ids from
the request body and the address from the recovered signature -- so no
other key can change an authorization outcome, and declaring one would
describe a boundary this service does not enforce. `signer` is there
because `rejectIfSigner` gates on it, and the fold leaves key casing
outside the signature: without it a legacy request could deliver
`Signer` and have the gate read the field as absent.

The fallback widens which signatures verify, not who may call. A
scene-signed request is still refused, and so is a re-spelled `signer`.
Removable once every caller signs the 6.x payload.

* refactor(auth): scope the legacy payload fallback to the read route

The declared key list was on the single shared middleware instance, so
it relaxed every signed route in the service. Only one of them needs it.

Checking what each caller actually sends: decentraland-dapps adds
`notificationIds` to the metadata on `PUT /notifications/read` and sends
an all-lowercase `{ signer, intent }` everywhere else, which ... (continued)

239 of 377 branches covered (63.4%)

Branch coverage included in aggregate %.

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

881 of 1016 relevant lines covered (86.71%)

20.73 hits per line