No description
  • Python 51.4%
  • JavaScript 20.8%
  • HTML 14.1%
  • CSS 12.1%
  • Shell 1.6%
Find a file
2026-11-06 21:38:03 +01:00
app feat: implement comprehensive logging and auditing features across the application 2026-11-06 21:06:57 +01:00
config feat: implement comprehensive logging and auditing features across the application 2026-11-06 21:06:57 +01:00
css Fix: reduce duration of save success flash animation for improved visibility 2026-11-06 21:32:25 +01:00
js fix: remove redundant declaration of kitToken and streamline initialization process 2026-11-06 21:38:03 +01:00
media favicon aktualisiert 2026-10-12 11:45:40 +02:00
test feat: implement comprehensive logging and auditing features across the application 2026-11-06 21:06:57 +01:00
.gitignore feat: implement comprehensive logging and auditing features across the application 2026-11-06 21:06:57 +01:00
admin.html feat: enhance admin UI with report search and export functionality 2026-10-06 17:48:26 +02:00
index.html fix: simplify exercise mode description in form footer 2026-10-19 20:37:35 +02:00
LICENSE Add initial implementation of Erste-Hilfe-Protokoll application 2026-10-05 19:05:29 +02:00
main.py feat: implement comprehensive logging and auditing features across the application 2026-11-06 21:06:57 +01:00
README.md feat: implement comprehensive logging and auditing features across the application 2026-11-06 21:06:57 +01:00
requirements.txt feat: implement email notifications for aid reports and configure SMTP settings 2026-10-08 21:28:24 +02:00
restart.sh feat: implement comprehensive logging and auditing features across the application 2026-11-06 21:06:57 +01:00
robots.txt Add initial implementation of Erste-Hilfe-Protokoll application 2026-10-05 19:05:29 +02:00

Erste-Hilfe-Protokoll

Webanwendung zur vertraulichen Dokumentation schulischer Erste-Hilfe-Leistungen. QR-Codes an den Koffern öffnen das vorausgefüllte Protokoll für den zugeordneten Raum. Die Anmeldung erfolgt über OIDC; nur Konten mit einer konfigurierten Lehrkraftrolle können Meldungen erfassen. /admin ist zusätzlich auf eine serverseitige Benutzerliste beschränkt.

Voraussetzungen

  • Python 3.10 oder neuer
  • Erreichbarer Keycloak-/OIDC-Server
  • Erreichbare Klassenlisten-API mit Lesezugriff auf Klassen und Personen
  • HTTPS-Reverse-Proxy für den Produktivbetrieb

Installation

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp config/config.py.sample config/config.py
cp config/admin.py.sample config/admin.py
cp config/popups.json.sample config/popups.json

config/config.py, config/admin.py und config/popups.json liegen ausschließlich auf dem Server und sind von Git ausgeschlossen. Zugangsdaten oder echte Benutzernamen nicht in die Sample-Dateien eintragen.

OIDC

In config/config.py OIDC-Issuer, Client-ID und Secret setzen. OIDC["redirect_uri"] muss exakt als erlaubte Redirect-URI des Keycloak-Clients eingetragen sein. Keycloak muss die Rolle im Claim sophomorixRole als teacher ausgeben. Falls die Installation einen anderen Wert liefert, APP["teacher_roles"] entsprechend konfigurieren. Ohne diese Rolle wird kein Formularzugriff gewährt.

Beim Laden der Hauptseite wird die Keycloak-Sitzung über eine OIDC-Anfrage mit prompt=none erneut geprüft. Bei fehlender Sitzung wird die lokale Anmeldung gelöscht und erneut angemeldet. Bereits geöffnete Seiten und direkte API-Aufrufe werden erst beim nächsten Laden der Hauptseite erneut geprüft; die Anwendung speichert weiterhin keine Sitzungen in SQLite. Die Prüfung benötigt eine Verbindung zu Keycloak.

Die Abmeldung beendet auch die Keycloak-Sitzung und damit gegebenenfalls die Sitzungen anderer verbundener Anwendungen. Keycloak kann eine Bestätigung verlangen. Optional kann OIDC["post_logout_redirect_uri"] auf eine in Keycloak als gültige Post-Logout-Redirect-URI registrierte Adresse gesetzt werden; ohne diese Einstellung zeigt Keycloak seine Abmeldeseite an.

APP["public_url"] ist die öffentliche HTTPS-Adresse der Anwendung und wird in die QR-Codes geschrieben. APP["https_only"] im Produktivbetrieb auf True belassen.

Klassenliste

In config/config.py die API-Basisadresse sowie Benutzername und Passwort in LMN setzen. Der Adapter meldet sich per HTTP-Basic-Auth über GET /v1/auth/ an und verwendet den zurückgegebenen Token im Header X-API-KEY. Klassen und Schüler werden über GET /v1/schoolclasses/ und GET /v1/schoolclasses/{class_cn}/students geladen. Die Endpoints sind in app/lmn.py festgelegt; die API muss die Datensätze als JSON-Listen mit den Feldern cn beziehungsweise firstname und lastname liefern. Wie im MassnahmenMonitor ist die TLS-Zertifikatsprüfung für die LMN-Verbindung deaktiviert (verify=False).

Die Anwendung gibt aus der Klassenliste nur Klassenbezeichnung und die genannten Personendaten an den Browser weiter. Wenn die lokale API ein anderes Schema liefert, app/lmn.py passend dazu anpassen.

Admin-Konten und Hinweise

In config/admin.py die OIDC-preferred_username-Werte der Admins in admins eintragen. Admins müssen zusätzlich die Lehrkraftrolle besitzen. Texte, Kategorien und DokuWiki-Adresse der Info-Pop-ups werden ausschließlich in config/popups.json gepflegt.

Start

source .venv/bin/activate
uvicorn main:app --host 127.0.0.1 --port 8001

Für einen Neustart auf dem Server kann bash restart.sh im Projektverzeichnis ausgeführt werden. Das Skript aktualisiert den aktuellen Git-Branch per Fast-Forward, gleicht die Pakete in .venv mit requirements.txt ab und startet main.py mit Host und Port aus config/config.py. Die Konfigurationsdatei und die virtuelle Umgebung müssen bereits eingerichtet sein.

Die Anwendung hinter einem HTTPS-Reverse-Proxy betreiben. Der Proxy muss die öffentliche Adresse und HTTPS-Sitzung korrekt weiterleiten. SQLite speichert die Daten in data/erste_hilfe.sqlite3; dieses Verzeichnis muss geschützt und regelmäßig gesichert werden.

Protokollierung

Anmeldung, Abmeldung, HTTP-Aktionen einschließlich PDF-Exporten, SQLite-Operationstypen, Transaktionen und Uvicorn-Meldungen werden in logs/application.log protokolliert. Der Pfad kann über APP["log_file"] geändert werden. Die Datei rotiert bei 10 MiB; fünf alte Dateien werden aufbewahrt. Neue Logdateien sind nur für den ausführenden Benutzer lesbar. Das Logverzeichnis muss für diesen Benutzer schreibbar sein und auch bei bestehenden Dateien vor fremdem Zugriff geschützt werden.

Bei einem systemd-Dienst schreibt die Anwendung zusätzlich über stderr ins Journal (journalctl -u <dienstname> -f). restart.sh nutzt auf Debian bei verfügbarem Journal systemd-cat: journalctl -t erstehilfemeldung -f. Ohne verfügbares Journal wird die Serverausgabe wie bisher in uvicorn.log geschrieben. Für dauerhaftes Journal müssen die systemd-Journal-Einstellungen des Servers entsprechend konfiguriert sein.

Die Audit-Ereignisse enthalten Benutzerkennung, Zeitpunkt, Aktion, Status, Clientadresse und Vorgangs-ID; SQLite- und PDF-Ereignisse können über die Vorgangs-ID zugeordnet werden. Es werden keine Formularinhalte, OAuth-Parameter oder SQL-Werte in diesen Ereignissen gespeichert; Schüler- und Klassenkennungen werden pseudonymisiert. Der Uvicorn-Standard-Access-Log ist deaktiviert, da er vollständige URLs mit sensiblen Parametern enthalten kann. Separate Proxy- und Keycloak-Logs müssen eigenständig geprüft und geschützt werden; Fehler-Stacktraces anderer Bibliotheken können dennoch sensible Angaben enthalten. Bei Reverse-Proxys hängt die protokollierte Clientadresse von der vertrauenswürdigen Proxy-Konfiguration ab.

Übungsläufe werden als exercise_report mit Benutzerkennung und Ergebnis (started, mail_sent oder mail_failed) protokolliert, ohne die eingegebenen Übungsdaten zu speichern.

Auch diese Logs enthalten personenbezogene Daten. Zugriff, Aufbewahrung und Löschung müssen mit dem Datenschutzkonzept abgestimmt werden. Die rotierenden Dateien und das Journal allein sind kein manipulationssicheres Auditarchiv; dafür ist eine separate geschützte Log-Sammlung erforderlich. Fehlgeschlagene Passwortprüfungen erfolgen bei Keycloak und stehen in dessen Logs.

Nutzung

  • Öffnen Sie / über den QR-Code am Erste-Hilfe-Koffer oder direkt in der Anwendung und melden Sie sich an. Datum/Uhrzeit und Ersthelfername werden vorbelegt. Der QR-Code wählt den zugehörigen Koffer und Raum voraus.
  • Wählen Sie die betroffene Person über Klasse und Schülerliste aus oder tragen Sie den Namen manuell ein. Klassen und Schüler werden aus der LMN-API geladen.
  • Dokumentieren Sie Datum und Uhrzeit des Ereignisses, den Hergang sowie Art und Umfang der Verletzung oder Erkrankung. Zeugen können optional eingetragen werden. Hergang und Gesundheitsschaden haben eigene Eingabefelder; Pflichtfelder sind im Formular gekennzeichnet.
  • Halten Sie Datum und Uhrzeit der Hilfeleistung, den Namen der Ersthelferin oder des Ersthelfers sowie die tatsächlich durchgeführten Maßnahmen fest. Textbausteine für Hergang, Art und Umfang, Maßnahmen sowie fehlendes Material werden in der Verwaltung gepflegt und können mehrfach eingefügt werden.
  • Melden Sie fehlendes Material nur, wenn der verbleibende Bestand für die Erste Hilfe nicht mehr ausreicht. Einzelne verbrauchte Teile müssen bei ausreichendem Restbestand nicht gemeldet werden.
  • Prüfen Sie die Angaben und speichern Sie das Protokoll. Fehlendes Material wird zusammen mit dem Protokoll gespeichert und in der Adminverwaltung angezeigt; es wird nicht automatisch per E-Mail weitergeleitet.
  • /admin ordnet die Bereiche Meldungssuche, Protokoll-Export, fehlendes Material, Kofferverwaltung und Textbausteine in dieser Reihenfolge an. Die Suche berücksichtigt Protokolle und Materialmeldungen. Erledigte Materialmeldungen werden mit Datum und Admin-Benutzer gespeichert und können eingeblendet werden.
  • Der Protokoll-Export erstellt ein PDF für einen wählbaren Zeitraum anhand des Unfalldatums; die Uhrzeit wird beim Filtern ignoriert. Die Protokolle enthalten alle erfassten Angaben außer fehlendem Material.
  • Für den QR-Code-PDF-Export sind zunächst alle aktiven Koffer ausgewählt. Die Auswahl kann einzeln oder gesammelt geändert werden; pro A4-Seite werden sechs direkt aneinanderliegende Felder mit 7 × 7 cm und QR-Codes mit 5 × 5 cm ausgegeben.

Datenschutz und Aufbewahrung

Die Erste-Hilfe-Aufzeichnungen enthalten besonders schützenswerte personenbezogene Angaben. Zugriff auf die Anwendung und die SQLite-Datei auf erforderliche Personen begrenzen, Übertragungen nur über HTTPS zulassen und Backups entsprechend schützen. Nach § 24 Abs. 6 DGUV Vorschrift 1 sind Aufzeichnungen fünf Jahre aufzubewahren und vertraulich zu behandeln. Die Anwendung löscht Protokolle nicht automatisch; Lösch- und Aufbewahrungsprozesse müssen mit dem schulischen Datenschutz- und Unfallversicherungsträger abgestimmt werden.