Admin Web Dashboard - Kontoregistrierung #2

New issue

Open

opened 2026-08-27 20:33:03 +02:00 by erdbruegger · 1 comment

erdbruegger commented

2026-08-27 20:33:03 +02:00

Owner

Aktuell kann man sich auf der Backend Seite einfach ein Konto registrieren. Das sollte nicht möglich sein, da es auch keinen Verifizierung Prozess gibt, beim installieren des Backends sollte also ein Admin-Konto automatisch erstellt werden und neue Konten aus dem Web Dashboard nur über diesen Admin erstellt werden können.
Im weiteren Verlauf sollte es später einen Registrierungsprozess geben (to bei defined), der die Erstellung eines Kontos unter den richtigen Umständen ermöglicht.

Unabhängig davon sind endpoints des Backends aktuell über das Benutzerkonto verifiziert/authentifiziert. Es sollte einen API Key Mechanismus unabhängig vom Benutzerkonto geben

Aktuell kann man sich auf der Backend Seite einfach ein Konto registrieren. Das sollte nicht möglich sein, da es auch keinen Verifizierung Prozess gibt, beim installieren des Backends sollte also ein Admin-Konto automatisch erstellt werden und neue Konten aus dem Web Dashboard nur über diesen Admin erstellt werden können. Im weiteren Verlauf sollte es später einen Registrierungsprozess geben (to bei defined), der die Erstellung eines Kontos unter den richtigen Umständen ermöglicht. Unabhängig davon sind endpoints des Backends aktuell über das Benutzerkonto verifiziert/authentifiziert. Es sollte einen API Key Mechanismus unabhängig vom Benutzerkonto geben

erdbruegger added the

claude

label

2026-08-27 20:33:08 +02:00

claudecode added the

in-progress

label

2026-08-27 20:44:23 +02:00

claudecode referenced this issue from a commit

2026-08-27 20:53:41 +02:00

release: Registrierung schliessen, Admin-Bootstrap, API-Keys (#2)

claudecode commented

2026-08-27 20:56:06 +02:00

Collaborator

Umgesetzt in d564dbe (release) — CI grün, deployt und live verifiziert.

1. Registrierung zu

POST /auth/register antwortet jetzt mit 403. ALLOW_REGISTRATION (Default false) öffnet die Route bewusst wieder, gedacht für lokale Entwicklung. Live geprüft:

$ curl -X POST .../auth/register -d '{"username":"testeindringling","password":"geheim123"}'
403 {"error":"registration disabled -- Konten legt ein Admin im Dashboard an"}
$ curl .../auth/config
{"allowRegistration":false,"userCount":2}

Im Dashboard ist die Registrieren-Ansicht weg — nur noch Login, mit dem Hinweis „Konten legt ein Administrator an."

2. Admin-Konto beim Installieren

Startet das Backend mit leerer users-Tabelle, legt es genau ein Admin-Konto an (src/auth/bootstrap.ts):

ADMIN_USERNAME (Default admin), ADMIN_PASSWORD, optional ADMIN_EMAIL — alle in .env.example und docker-compose.yml ergänzt.
Ohne ADMIN_PASSWORD wird eines erzeugt und einmalig ins Server-Log geschrieben (docker compose logs backend). Ein gesetztes ADMIN_PASSWORD taucht nie im Log auf.
Idempotent: existiert schon ein Nutzer, passiert nichts. Auf deiner Instanz ist damit nichts passiert — dort sind 2 Konten, dein Admin bleibt unverändert.

Neu dazu: POST /auth/password (eigenes Passwort ändern). Ohne das bliebe ein generiertes Bootstrap-Passwort dauerhaft im Log stehen.

3. API-Keys, unabhängig vom Benutzerkonto

Neue Tabelle api_keys — gespeichert wird nur der SHA-256-Hash, der Klartext (oaw_…) ist genau einmal bei der Erstellung sichtbar. Verwendung:

curl "$BASE/vehicles" -H "X-API-Key: oaw_..."
curl "$BASE/vehicles" -H "Authorization: Bearer oaw_..."   # geht auch

Gelten für: Query-API, Command-Queue und alle Ingest-Endpunkte — dort als Alternative zum gemeinsamen DEVICE_TOKEN, damit der ESP-Kurier/die Bridge ohne Benutzerkonto auskommt.
Gelten nicht für Kontoverwaltung (/auth/me, /auth/password, /users, /api-keys): dort verlangt der Server einen echten Login. Auch ein Key mit Rolle admin kommt dort nicht durch — sonst könnte sich ein abgegriffener Key selbst weitere Schlüssel und Konten ausstellen.
Rolle user/admin, optionales Ablaufdatum, sofort wirksamer Widerruf (markiert statt gelöscht, damit die Historie bleibt), last_used_at wird höchstens einmal pro Minute geschrieben.
Dashboard: neuer Admin-Tab API-Keys (anlegen, Status aktiv/abgelaufen/widerrufen, widerrufen).

Entscheidungen (proceed-with-default)

Kontoverwaltung bleibt dem Login vorbehalten, siehe oben. Falls du später doch reine Maschinen-Provisionierung willst, wäre ein eigener scope-Wert am Key der saubere Weg.
Verhalten bei leerem DEVICE_TOKEN unverändert gelassen: ohne gesetztes Token bleibt Ingest offen wie bisher. Das ist streng genommen ein Loch, aber es zu schließen hätte jede Installation ohne Token still lahmgelegt. Stattdessen warnt der Server jetzt beim Start. Sag Bescheid, wenn ich das hart machen soll.
created_by bei Commands ist bei API-Key-Requests null statt eines erfundenen Nutzers.
Der Registrierungsprozess mit Verifizierung (to be defined) ist bewusst nicht enthalten — dafür braucht es erst eine Entscheidung, wie verifiziert wird (E-Mail? Einladungscode?).

Verifikation

48 End-to-End-Tests gegen echtes Postgres (lokal, echter Server): Registrierung zu, Bootstrap in beiden Varianten und idempotent beim Neustart, Key anlegen/nutzen/widerrufen/ablaufen lassen, Rollen- und Session-Grenzen, Ingest mit Device-Token und mit Key, Passwortwechsel inklusive Fehlerfällen, last_used_at.
18 jsdom-Tests des Dashboards: kein Registrieren-Link mehr, API-Keys-Tab nur für Admins, Anlegen mit Rolle/Ablauf, einmalige Klartextanzeige mit Warnung, Widerrufen, Nicht-Admin sieht die Verwaltungstabs nicht.
13 neue API-Key-Fälle in src/auth/selftest.ts — laufen in der CI mit.
Live nach dem Deploy: register → 403, allowRegistration: false, /api-keys → 401 statt 404, erfundener Key → 401, Ingest mit deinem echten DEVICE_TOKEN weiter 200, mit falschem 401, Dashboard enthält den API-Keys-Tab.

Zwei Hinweise

Deine zwei bestehenden Konten sind unverändert und melden sich weiter normal an. Neue Konten legst du ab jetzt im Tab Nutzer an.
Nebenbei aufgefallen: GET /sandbox.json antwortet auf der Live-Instanz mit 200, d. h. dort ist NODE_ENV nicht auf production gesetzt. Die Sandbox zeigt nur die Endpunktliste, keine Secrets — ich habe das deshalb nicht angefasst. Wenn sie draußen nicht erreichbar sein soll: NODE_ENV=production in /opt/openaiways/.env.

**Umgesetzt** in `d564dbe` (release) — CI grün, deployt und live verifiziert. ### 1. Registrierung zu `POST /auth/register` antwortet jetzt mit **403**. `ALLOW_REGISTRATION` (Default `false`) öffnet die Route bewusst wieder, gedacht für lokale Entwicklung. Live geprüft: ``` $ curl -X POST .../auth/register -d '{"username":"testeindringling","password":"geheim123"}' 403 {"error":"registration disabled -- Konten legt ein Admin im Dashboard an"} $ curl .../auth/config {"allowRegistration":false,"userCount":2} ``` Im Dashboard ist die Registrieren-Ansicht weg — nur noch Login, mit dem Hinweis „Konten legt ein Administrator an." ### 2. Admin-Konto beim Installieren Startet das Backend mit leerer `users`-Tabelle, legt es genau ein Admin-Konto an (`src/auth/bootstrap.ts`): - `ADMIN_USERNAME` (Default `admin`), `ADMIN_PASSWORD`, optional `ADMIN_EMAIL` — alle in `.env.example` und `docker-compose.yml` ergänzt. - Ohne `ADMIN_PASSWORD` wird eines erzeugt und **einmalig ins Server-Log** geschrieben (`docker compose logs backend`). Ein gesetztes `ADMIN_PASSWORD` taucht nie im Log auf. - Idempotent: existiert schon ein Nutzer, passiert nichts. **Auf deiner Instanz ist damit nichts passiert** — dort sind 2 Konten, dein Admin bleibt unverändert. Neu dazu: `POST /auth/password` (eigenes Passwort ändern). Ohne das bliebe ein generiertes Bootstrap-Passwort dauerhaft im Log stehen. ### 3. API-Keys, unabhängig vom Benutzerkonto Neue Tabelle `api_keys` — gespeichert wird **nur der SHA-256-Hash**, der Klartext (`oaw_…`) ist genau einmal bei der Erstellung sichtbar. Verwendung: ```bash curl "$BASE/vehicles" -H "X-API-Key: oaw_..." curl "$BASE/vehicles" -H "Authorization: Bearer oaw_..." # geht auch ``` - **Gelten für:** Query-API, Command-Queue und alle Ingest-Endpunkte — dort als Alternative zum gemeinsamen `DEVICE_TOKEN`, damit der ESP-Kurier/die Bridge ohne Benutzerkonto auskommt. - **Gelten nicht für Kontoverwaltung** (`/auth/me`, `/auth/password`, `/users`, `/api-keys`): dort verlangt der Server einen echten Login. **Auch ein Key mit Rolle `admin` kommt dort nicht durch** — sonst könnte sich ein abgegriffener Key selbst weitere Schlüssel und Konten ausstellen. - Rolle `user`/`admin`, optionales Ablaufdatum, sofort wirksamer Widerruf (markiert statt gelöscht, damit die Historie bleibt), `last_used_at` wird höchstens einmal pro Minute geschrieben. - Dashboard: neuer Admin-Tab **API-Keys** (anlegen, Status aktiv/abgelaufen/widerrufen, widerrufen). ### Entscheidungen (proceed-with-default) - **Kontoverwaltung bleibt dem Login vorbehalten**, siehe oben. Falls du später doch reine Maschinen-Provisionierung willst, wäre ein eigener `scope`-Wert am Key der saubere Weg. - **Verhalten bei leerem `DEVICE_TOKEN` unverändert gelassen:** ohne gesetztes Token bleibt Ingest offen wie bisher. Das ist streng genommen ein Loch, aber es zu schließen hätte jede Installation ohne Token still lahmgelegt. Stattdessen warnt der Server jetzt beim Start. Sag Bescheid, wenn ich das hart machen soll. - `created_by` bei Commands ist bei API-Key-Requests `null` statt eines erfundenen Nutzers. - **Der Registrierungsprozess mit Verifizierung (to be defined) ist bewusst nicht enthalten** — dafür braucht es erst eine Entscheidung, wie verifiziert wird (E-Mail? Einladungscode?). ### Verifikation - **48 End-to-End-Tests gegen echtes Postgres** (lokal, echter Server): Registrierung zu, Bootstrap in beiden Varianten und idempotent beim Neustart, Key anlegen/nutzen/widerrufen/ablaufen lassen, Rollen- und Session-Grenzen, Ingest mit Device-Token und mit Key, Passwortwechsel inklusive Fehlerfällen, `last_used_at`. - **18 jsdom-Tests** des Dashboards: kein Registrieren-Link mehr, API-Keys-Tab nur für Admins, Anlegen mit Rolle/Ablauf, einmalige Klartextanzeige mit Warnung, Widerrufen, Nicht-Admin sieht die Verwaltungstabs nicht. - **13 neue API-Key-Fälle** in `src/auth/selftest.ts` — laufen in der CI mit. - **Live nach dem Deploy:** `register` → 403, `allowRegistration: false`, `/api-keys` → 401 statt 404, erfundener Key → 401, Ingest mit deinem echten `DEVICE_TOKEN` weiter 200, mit falschem 401, Dashboard enthält den API-Keys-Tab. ### Zwei Hinweise 1. **Deine zwei bestehenden Konten sind unverändert** und melden sich weiter normal an. Neue Konten legst du ab jetzt im Tab *Nutzer* an. 2. Nebenbei aufgefallen: `GET /sandbox.json` antwortet auf der Live-Instanz mit 200, d. h. dort ist `NODE_ENV` nicht auf `production` gesetzt. Die Sandbox zeigt nur die Endpunktliste, keine Secrets — ich habe das deshalb nicht angefasst. Wenn sie draußen nicht erreichbar sein soll: `NODE_ENV=production` in `/opt/openaiways/.env`.

claudecode added

needs-review

and removed

in-progress

labels

2026-08-27 20:56:06 +02:00