| Filename | Latest commit message | Latest commit date |
|---|---|---|
78217bc10f
The wire crate's module doc and its README both said the bridge "owns both users.json (canonical) and rendering users.yml internally". That store was removed — swarm-authelia-bridge/src/store.rs is explicit that users.yml *is* the store — so both sentences described a file that does not exist, in the one place a reader goes to learn what the API is for. The paragraph's actual argument (per-operation rather than wholesale-replace) is untouched; only the mechanism it cites was wrong. |
||
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
swarm-authelia-bridge-sock
Wire types for the swarm-authelia-bridge socket — the contract between
swarm-authelia-bridge (server, runs alongside swarm-authelia) and
swarm-controller (client).
Why it's its own crate
Same rationale as hive-priv-sock (which this mirrors in spirit, though the
transport differs — this bridge is network-facing HTTP, not a unix socket,
since it has to reach a possibly-split-host swarm-controller): the bridge
is a narrowly-scoped, unprivileged-but-file-owning helper, and splitting the
wire contract out of any larger crate keeps both its own dependency
footprint and its interface small enough to audit at a glance. No server or
client logic here, only the request/response shapes both sides import.
Shape
One operation today: idempotently ensure an agent exists as an authelia
subject. Deliberately not a wholesale-replace-the-file API — the bridge
reads users.yml, changes what the request named, and writes it back; a
caller only ever asks for one user to exist, never sends rendered YAML or a
file blob. See swarm-authelia-bridge/README.md for the helper itself.