Thomas Stallinger
19b39af0ce
Zwei neue Menuepunkte fuer eingeloggte Kunden (nicht der organisationsuebergreifende /admin/-Bereich): - "Organisation": Name bearbeiten (ruft Phase-3-PATCH auf provisioning-server auf). - "Installationsmedium": WLAN-SSID/-Passwort, Vorlagenwahl, Kontingent und Gueltigkeitsdauer speichern, personalisierte Kunden-ISO per Klick erstellen (Phase-4-Endpoints), Fortschritt/Status-Anzeige (Meta-Refresh waehrend pending/running), Download + dd/Rufus- Anleitung. Getrennte "aufladen"-Aktion erhoeht Kontingent/ Gueltigkeit der bestehenden Enrollment Session (neuer PATCH- Endpoint), ohne eine neue ISO zu erzeugen - die bereits ausgeteilte bleibt gueltig. Neue Tabelle installationsmedium_konfiguration (Migration 0004, eigene DB, kein Foreign Key auf provisioning-server-Ressourcen, siehe ADR-0011) haelt SSID/verschluesselten PSK/Vorlage/Kontingent-Defaults sowie die IDs der aktuell gueltigen Enrollment Session und des zugehoerigen ISO-Baus. WLAN-PSK wird Fernet-verschluesselt gespeichert (encryption.py, neuer KUNDENPLATTFORM_ENCRYPTION_KEY) - echte Zugangsdaten, kein Passwort-Hash-Fall. Download laeuft ueber einen Streaming-Proxy (anode_stream() in anode_client.py) statt eines direkten Links, weil der Browser kein KUNDENPLATTFORM_TOKEN besitzt. Lokal end-to-end verifiziert (Wegwerf-Postgres fuer beide Services, echter build_customer_iso.sh-Lauf ueber die Kundenplattform-UI): Formular -> Enrollment Session + ISO-Bau -> Status-Polling -> Download-Proxy liefert byte-identische, korrekt personalisierte Datei (SSID/PSK/Aktivierungscode per xorriso-Extraktion gegengeprueft) -> Aufladen erhoeht Kontingent/Gueltigkeit der bestehenden Session ohne neuen Bau -> "neues Installationsmedium erstellen" erzeugt neue Session + ISO, alte Session bleibt unangetastet nutzbar (alter ISO-Bau wird laut Phase-4-Cleanup automatisch entfernt), leeres PSK-Feld uebernimmt das zuvor gespeicherte PSK korrekt. Organisation-Name-Aenderung ueber PATCH verifiziert. Unauthentifizierter Zugriff auf beide neuen Routen leitet korrekt zu /login um. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
33 lines
1.4 KiB
PL/PgSQL
33 lines
1.4 KiB
PL/PgSQL
BEGIN;
|
|
|
|
-- Phase 5 des Self-Service-ISO-Plans: gespeicherte Installationsmedium-
|
|
-- Konfiguration je Organisation (WLAN-Zugangsdaten, gewaehlte
|
|
-- Bereitstellungsvorlage, Enrollment-Session-Parameter). Wie
|
|
-- benutzer.organization_id bewusst ohne Foreign Key - Kundenplattform hat
|
|
-- eine eigene, von provisioning-server getrennte Datenbank (siehe
|
|
-- ADR-0011). Ein Datensatz je Organisation reicht (organization_id ist
|
|
-- Primary Key statt eigener id-Spalte) - es gibt genau eine "aktuelle"
|
|
-- Konfiguration, keine Historie.
|
|
--
|
|
-- wifi_psk_encrypted: echte WLAN-Zugangsdaten, kein Passwort-Hash-Fall -
|
|
-- muss entschluesselbar bleiben (wird beim ISO-Bau im Klartext an
|
|
-- build_customer_iso.sh durchgereicht, siehe encryption.py), daher
|
|
-- Fernet-verschluesselt statt gehasht.
|
|
--
|
|
-- enrollment_session_id/iso_build_id verweisen auf provisioning-server-
|
|
-- Ressourcen (ebenfalls ohne Foreign Key, andere Datenbank). Beide sind
|
|
-- nullable, bis das erste Installationsmedium erstellt wurde.
|
|
CREATE TABLE installationsmedium_konfiguration (
|
|
organization_id UUID PRIMARY KEY,
|
|
wifi_ssid TEXT,
|
|
wifi_psk_encrypted BYTEA,
|
|
bereitstellungsvorlage_id UUID,
|
|
max_devices INTEGER NOT NULL DEFAULT 20,
|
|
validity_days INTEGER NOT NULL DEFAULT 30,
|
|
enrollment_session_id UUID,
|
|
iso_build_id UUID,
|
|
updated_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
|
|
);
|
|
|
|
COMMIT;
|