Section 01
Simple Explanation
Ein echter Secure Room ist wie eine Eingangskontrolle in einem privaten Gebäude. Der Nutzer gibt seine E-Mail und sein Passwort ein. Dann prüft nicht der Browser, sondern der Server, ob diese Anmeldung erlaubt ist.
Wenn die Anmeldung korrekt ist, erstellt der Server eine sichere Sitzung. Diese Sitzung merkt sich: Dieser Nutzer ist eingeloggt. Danach darf der Nutzer nur das sehen, was zu seiner Rolle und seinem Kundenraum passt.
Wichtig: Ein schönes Secure Room-Formular allein schützt nichts. Der Schutz entsteht erst durch Backend-Prüfung, sichere Passwortspeicherung, Rollen und serverseitige Zugriffskontrolle.
Section 02
Secure Room Flow
| Schritt | Was passiert? | Warum wichtig? |
|---|---|---|
| 1 | Nutzer öffnet die Secure Room-Seite. | Der Nutzer sieht nur ein Formular, noch keine geschützten Daten. |
| 2 | Nutzer gibt E-Mail und Passwort ein. | Die Zugangsdaten werden an das Backend gesendet. |
| 3 | Backend sucht den Nutzer in der Datenbank. | Nur bekannte Nutzer dürfen weiter geprüft werden. |
| 4 | Backend vergleicht das Passwort sicher. | Das echte Passwort wird nicht offen gespeichert. |
| 5 | Backend erstellt eine Session. | Der Server merkt sich sicher, dass der Nutzer eingeloggt ist. |
| 6 | Nutzer wird zum Dashboard weitergeleitet. | Er sieht nur die Daten, die seine Rolle sehen darf. |
Section 03
User Roles
| Rolle | Einfach erklärt | Darf später |
|---|---|---|
| Super Admin | Hauptverwalter des gesamten Systems. | Alles verwalten: Nutzer, Kunden, Dokumente, Rollen, Rechte. |
| Admin | Interner Verwalter mit begrenztem Zugriff. | Kundenräume und Dokumente verwalten, wenn freigegeben. |
| Client User | Kundenbenutzer mit eigenem Kundenraum. | Nur eigene freigegebene Dokumente sehen. |
| Viewer | Sehr eingeschränkter Leser. | Nur bestimmte Dokumente ansehen, keine Verwaltung. |
Section 04
Password Security
Passwörter dürfen später niemals als Klartext gespeichert werden. Das bedeutet: In der Datenbank darf nicht stehen: „meinPasswort123“.
Stattdessen wird aus dem Passwort ein sicherer Hash erstellt. Ein Hash ist wie ein Fingerabdruck des Passworts. Man kann prüfen, ob ein Passwort passt, aber man soll aus dem Hash nicht einfach das echte Passwort zurückholen können.
| Bereich | Unsicher | Sicherer Ansatz |
|---|---|---|
| Passwortspeicherung | Passwort offen in Datenbank speichern | Passwort mit bcrypt oder ähnlichem Verfahren hashen |
| Passwortprüfung | Im Browser prüfen | Im Backend prüfen |
| Fehlermeldungen | „E-Mail existiert nicht“ | Neutral: „Secure Room-Daten ungültig“ |
| Passwort im Code | Passwort hart im Code eintragen | Niemals Passwörter im Code speichern |
Section 05
Session Logic
Eine Session ist wie ein zeitlich begrenzter Besucherausweis. Nach erfolgreichem Secure Room bekommt der Nutzer eine sichere Session. Danach erkennt der Server bei jeder Anfrage: Dieser Nutzer ist eingeloggt.
| Baustein | Einfach erklärt | Später notwendig |
|---|---|---|
| Session Cookie | Der Browser bekommt ein kleines sicheres Kennzeichen. | HttpOnly, Secure, SameSite setzen. |
| Session Store | Der Server speichert aktive Sitzungen. | Nicht nur im Browser vertrauen. |
| Logout | Die Sitzung wird beendet. | Session serverseitig löschen. |
| Session Ablauf | Nach einer Zeit wird die Sitzung ungültig. | Schutz bei vergessenen offenen Geräten. |
Section 06
Access Control
Secure Room beantwortet nur die Frage: Wer bist du? Zugriffskontrolle beantwortet die zweite Frage: Was darfst du sehen?
Beide Dinge sind wichtig. Ein eingeloggter Kunde darf trotzdem nicht automatisch alle Dokumente sehen.
| Prüfung | Beispiel | Warum? |
|---|---|---|
| Ist der Nutzer eingeloggt? | Session existiert | Ohne Secure Room kein Zugriff. |
| Welche Rolle hat der Nutzer? | Admin oder Client User | Admin und Kunde dürfen nicht dasselbe sehen. |
| Zu welchem Kunden gehört der Nutzer? | client_demo_a | Kunde A darf nicht Kunde B sehen. |
| Darf der Nutzer dieses Dokument sehen? | document_permissions prüfen | Jede Datei braucht Rechteprüfung. |
Section 07
Unsafe vs Safe
| Unsicher | Sicherer Ansatz | Grund |
|---|---|---|
| Secure Room nur mit JavaScript im Browser prüfen | Secure Room im Backend prüfen | Browser-Code kann manipuliert werden. |
| Passwort offen speichern | Passwort hashen | Schutz bei Datenbankleck. |
| Nach Secure Room alle Dokumente anzeigen | Jede Datei einzeln prüfen | Verhindert Kundendaten-Leaks. |
| Admin-Seite ohne Schutz lassen | Admin-Seite nur nach Admin-Secure Room | Admin-Bereich ist besonders sensibel. |
| Dateilinks direkt öffentlich machen | Backend-gesteuerte Downloads | Link allein ist kein Zugriffsschutz. |
Section 08
Next Development Step
Der nächste sinnvolle Schritt ist eine lokale Authentifizierungs-Grundlage. Dafür erstellen wir zuerst Demo-Nutzer in einer lokalen Datei. Danach bauen wir eine Secure Room-API, die Demo-Secure Room-Daten prüft.
Wichtig: Auch der erste Secure Room wird noch ein lokaler Prototyp sein. Wir verwenden keine echten Passwörter und keine echten Kundendaten.