Ilia Denisov
91e34a0929
ARCHITECTURE.md §15 "Verification order" specifies signature verification (step 4) before payload_hash (step 5), but the authenticated-edge decorator chain wrapped the payload-hash gate outside the signature gate, so the hash was checked first. gateway/README.md and gateway/docs/flows.md had drifted to match the code (hash-first), leaving ARCHITECTURE.md as the lone source describing the intended order. Swap the two decorators in server.go so the signature gate runs first, and align README + flows.md to ARCHITECTURE.md. Signature-first is the cryptographically sound order: the signature covers the payload_hash field, so the request is authenticated before any of its content is processed. Observable side effect: a request carrying a tampered payload_hash whose signature was computed over the original hash is now rejected at the signature gate (UNAUTHENTICATED "invalid request signature") instead of the hash gate (INVALID_ARGUMENT). Security is unchanged — both refusals happen before the payload is handled. The four payload-hash unit tests re-sign over the tampered hash so they keep exercising the hash gate; the cross-service integration test signs over the overridden hash and already accepts both codes. Refs #39 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Edge Gateway Docs
This directory keeps service-local documentation that is too detailed for the root architecture documents and too diagram-heavy for the module README.
Sections:
- Runtime and components
- Public auth, command, and push flows
- Operator runbook
- Configuration and contract examples
- Example
.env
Primary references:
../README.mdfor service scope, contracts, configuration, and operational behavior../openapi.yamlfor the public REST contract../../README.mdfor workspace-level architecture../../SECURITY.mdfor the transport security model