Repository navigation
Wire parsers for the spec'd endpoints core doesn't parse yet #354
Description
#353 makes the ./wire parsers refuse input their endpoint doesn't define (docs/spec/wire-format.md § Unrecognized input). It only covers endpoints that already have a parser in core: GET /records, POST /records/query, POST /records, PATCH /records/:id, GET /changes and the journal.
The endpoints below are also defined in core's spec, but each server parses their input itself. So every server has to repeat the list of param and field names and apply the strictness rule on its own. haverstack/server#130 does this today with knownParams() and a key list passed to readJson(). Those lists copy names core defines, so they can drift out of step with core.
Endpoints
| Endpoint | Input to parse | Spec |
|---|---|---|
POST /auth/challenge |
body { did } |
identity.md, wire-format.md § Authentication |
POST /auth/token |
body { did, nonce, signature } |
same |
PATCH /entity |
body { content } |
wire-format.md § Entity |
POST /types |
body: a StackType. baseId, version and createdAt are accepted and ignored. |
wire-format.md § Types |
POST /records/:id/migrate |
body { toTypeId, content } |
wire-format.md § Migration commit |
DELETE /records/:id |
?purge= (boolean) |
wire-format.md § Records |
GET /attachments/:fileId |
?contentType=, ?filename= |
wire-format.md § Download |
GET /records/:id/associations |
?kind=, ?label= |
wire-format.md § Associations |
For each one, add a parser to @haverstack/core/wire that:
- returns the typed input,
- throws
StackBadRequestErrorfor an unknown name or a malformed boolean, - throws
StackValidationErrorfor a known field whose value has the wrong type.
This follows the pattern of the existing parsers. Add error fixtures where they pin behavior a server might get wrong. The server then calls these parsers instead of its own lists.
Endpoints that only the server defines stay in the server: /tokens, /attachments/gc, /health.
Also missing: unknown keys inside grant and association elements
Elements sent to the permissions and associations endpoints are still accepted when they carry keys their kind doesn't define, for example { kind: 'entity', entityId, scope } on a grant target. validateGrantTarget() and validateAssociation() check that required fields are present, but don't check for unknown ones. This is element validation in Stack rather than wire parsing, because the same elements arrive through create() and imports. It needs its own decision: refusing unknown keys at write time would also refuse elements already stored that carry them.
Activity
feat(core): refuse unknown keys on association, permission and grant-…