Vom Backend geladen
Consortium Vault
Dynamic Admin Panel
Lokaler Admin-Prototyp, der Demo-Kunden, Demo-Dokumente und Demo-Berechtigungen live aus dem lokalen Backend lädt.
Vom Backend geladen
Demo-Zuweisungen
Kein echter Admin-Schutz
Section 01
Admin Overview
Dieses Admin Panel zeigt jetzt Demo-Daten aus dem Backend. Das bedeutet: Die Kunden, Dokumente und Berechtigungen stehen nicht mehr fest im HTML-Code, sondern werden aus der Prototype Data API geladen.
Das ist ein wichtiger Schritt Richtung echtes Admin-System. Später wird hier ein echter Admin nach Secure Room Kunden anlegen, Dokumente verwalten und Zugriffsrechte steuern können.
Section 02
Dynamic Client Register
Diese Tabelle lädt Demo-Kunden aus der Datei database/prototype-data.json über das Backend.
| Kunde | Status | Secure Room | Access Level |
|---|---|---|---|
| Demo-Kunden werden geladen... | |||
Section 03
Dynamic Document Register
Diese Tabelle lädt Demo-Dokumente aus dem Backend. Nur Dokumente mit publicPrototype: true sind im lokalen Prototyp direkt öffnbar.
| Dokument | Typ | Status | Sichtbarkeit |
|---|---|---|---|
| Demo-Dokumente werden geladen... | |||
Section 04
Dynamic Permission Register
Diese Tabelle zeigt die Demo-Zuweisungen zwischen Kunden und Dokumenten. Das ist noch keine echte Zugriffskontrolle, aber die spätere Logik wird hier vorbereitet.
| Client ID | Document ID | Permission |
|---|---|---|
| Demo-Berechtigungen werden geladen... | ||
Section 05
Security Notes
Auch wenn dieses Admin Panel jetzt dynamische Daten aus dem Backend lädt, ist es noch nicht geschützt. Jeder, der lokal die URL kennt, kann die Seite öffnen.
| Bereich | Aktueller Stand | Später notwendig |
|---|---|---|
| Admin-Zugang | Kein echter Secure Room | Admin-Secure Room mit sicherer Session |
| Kundenverwaltung | Nur Demo-Daten lesen | Kunden erstellen, bearbeiten, sperren |
| Dokumentenverwaltung | Nur Demo-Daten lesen | Upload, Versionierung, Freigabe, Sperrung |
| Berechtigungen | Nur Demo-Zuweisungen | Serverseitige Rechteprüfung |
| Audit Log | Noch nicht aktiv | Admin-Aktionen müssen protokolliert werden |
Section 06
Next Steps
Der nächste sinnvolle Schritt ist ein Secure Room Architecture Blueprint. Bevor wir echten Secure Room programmieren, legen wir sauber fest: Welche Benutzerarten gibt es? Wie werden Passwörter gespeichert? Wie funktioniert eine Session? Was darf niemals im Browser geprüft werden?
Danach starten wir mit der echten lokalen Secure Room-Grundlage.