hub-db

← All modules

4 endpoints.

POST /api/v1/hub-db/session

Session

Trade the caller's Bearer token for the /dbm cookie.

Called by the page on mount, before the iframe is rendered — the iframe's very first request already needs the cookie, so this must complete first.

200 — Successful Response

{
  "additionalProperties": true,
  "type": "object",
  "title": "Response Session Api V1 Hub Db Session Post"
}

---

DELETE /api/v1/hub-db/session

End Session

Drop the cookie. The page calls this when it unmounts, so closing the Database Manager actually closes the door rather than leaving an 8-hour pass sitting in the browser.

200 — Successful Response

{
  "additionalProperties": true,
  "type": "object",
  "title": "Response End Session Api V1 Hub Db Session Delete"
}

---

GET /api/v1/hub-db/authz

Authz

nginx's auth_request target. 204 = let it through, 401 = don't.

Deliberately NOT require_superuser: an iframe sub-request carries no Authorization header, only the cookie, which is the whole reason this endpoint exists. It therefore does its own verification, and does it without touching the database — this runs on EVERY request the console makes, and a per-request user lookup would put a query in front of every bundle, GraphQL call and websocket frame.

That the token is signed with our SECRET_KEY, carries type=dbm and is bound to the hub site is what stands in for the row: only :func:session mints one, and only a superuser on the hub can call that.

200 — Successful Response

{}

---

GET /api/v1/hub-db/status

Status

Is the console actually up?

The page asks before it renders the iframe. Without this a stopped container is a silent blank rectangle; with it the page can say "the Database Manager is not running" and name the container to restart.

200 — Successful Response

{
  "additionalProperties": true,
  "type": "object",
  "title": "Response Status Api V1 Hub Db Status Get"
}