v0.13.0
Per-request authorization
The portal can now require a credential on the data API and decide, for each request, whether the caller is entitled to the dataset it asks for. It is opt-in: a portal with no authorization configured keeps byte-for-byte the behaviour it had before.
- Asks once, then answers locally. The portal holds no key set. The first request presenting a credential exchanges it with the issuing side for a short-lived grant, and every later request is decided in process until that grant runs out — so the authority's latency does not sit in front of every query.
- Closed on the credential, retryable on the dependency. An exchange that could not run is not a claim about the key, so it is answered as overload or upstream unavailability rather than as a bad credential. Refusals share one status whichever rung they fail at, so the status line never tells a guesser which guess to keep; the error code still says which, to whoever already holds the key.
- A signing identity of its own. The exchange can be signed with a key of its own rather than the portal's network identity, so one host can hold more than one registration.
- The archival head no longer moves backwards. An assignment older than the one in force is now rejected and counted rather than applied — applying one dropped chunks the portal had already advertised, and left a range no source covered until the next poll recovered.
Breaking for deployments that turn authorization on: it publishes its own metric families, which dashboards and alerts follow, and a configuration this build cannot fully recognise refuses to start rather than serving the data API ungated.
See spec/02-requirements.md for the contract and spec/15-parameters.md for what an operator can bind. (#143, #146, #148, #149)
Full Changelog: v0.12.1...v0.13.0