105 lines
6.4 KiB
Markdown
105 lines
6.4 KiB
Markdown
# Projektstand
|
|
|
|
**Version:** 0.1.0-alpha.5
|
|
**Datum:** 2026-09-15
|
|
|
|
## Fertig in diesem Snapshot
|
|
|
|
### Outbox, Mail, weitere Provider und Betrieb (alpha.5)
|
|
|
|
- SQLite-Outbox mit atomarer Annahme, expliziter Deduplizierung, Lease-Recovery und Retry/Backoff.
|
|
- Pro Ziel gespeicherter Versandauftrag einschließlich ursprünglicher Live-/Dry-Run-Einstellung.
|
|
- SMTP-Ausgang mit TLS/STARTTLS, IMAP-Eingang mit UID-/UIDVALIDITY-Checkpoint und MIME-Text.
|
|
- ntfy- und Gotify-Ausgänge sowie signierter Discord-Slash-Command-Eingang.
|
|
- WebUI für neue Provider, Mail-/Discord-Eingänge, Historie und manuelle Wiederholung.
|
|
- Readiness, geschützte Prometheus-Zustandsmetriken und graceful Shutdown.
|
|
- bcrypt mit Legacy-Migration, CSRF/Origin-Prüfung, CSP, Login- und Body-Limits, `env:`-Secrets.
|
|
- Betrieb, Konfiguration und Grenzen dokumentiert in [OPERATIONS.md](OPERATIONS.md).
|
|
- **API-Änderung:** HTTP-Eingänge liefern 202 nach Speicherung; Versandstatus steht in der Historie.
|
|
|
|
### Provider-Erweiterung (2026-09-15, auf Basis alpha.4)
|
|
|
|
- Benannte Discord-/HTTP-Webhook-Ausgänge mit Live-Opt-in, Timeout und optionalem Bearer-Token.
|
|
- Neuer WebUI-Bereich **Ausgänge**, Zuordnung pro Regel und Vorschau für beide Provider.
|
|
- Unabhängige Zustellung über mehrere Regeln mit Einzelergebnissen bei Teilfehlern.
|
|
- Discord-Mentions deaktiviert, Längenlimit geprüft; HTTP-Redirects blockiert und neue Transportfehler ohne URL-/Token-Leaks.
|
|
- Regression behoben: identische Regex für mehrere Felder werden jeweils ausgewertet.
|
|
- Ausbauplan für Outbox, Mail und weitere Ein-/Ausgänge: [PROVIDER_PLAN.md](PROVIDER_PLAN.md).
|
|
|
|
### Bisheriger Funktionsumfang
|
|
|
|
- Go-Server mit persistentem JSON-Store und Admin-Authentifizierung
|
|
- neue formularbasierte WebUI statt JSON-Texteditor
|
|
- getrennte Bereiche für Divera247, Eingänge, Zuordnungen und Server/Sicherheit
|
|
- Divera247-Zugang mit Accesskey, UCR, Timeout und Dry-Run konfigurierbar
|
|
- Divera247 `pull/all` aus der WebUI; lesende Aufrufe bleiben auch im Dry-Run möglich
|
|
- Personenabruf primär über v2 `pull/all` aus `data.cluster.consumer`; numerische Collection-Keys werden als UCR-IDs verwendet
|
|
- robuster v2-Fallback: numerische `cluster.consumer`-Schlüssel werden als UCR-ID erhalten und nicht mit globalen User-IDs verwechselt
|
|
- automatische Aufbereitung geladener Stammdaten für Einheiten, Gruppen, Personen und Fahrzeuge
|
|
- Mehrfacheinheiten werden über `data.ucr` erkannt und parallel mit begrenzter Konkurrenz über v2 `pull/all?ucr=...` geladen
|
|
- visueller Regel-Editor für Quelle/Kanal/Titel/Meldung/Priorität
|
|
- Divera247-Stichwort, Meldung, Adresse, Zieltyp und Versandwege als Formularfelder
|
|
- einheitsübergreifende Alarmierung mit Empfängerart Alle/Gruppen/Personen pro Einheit
|
|
- durchsuchbare Auswahl von Gruppen, Personen und Fahrzeugen mit manueller ID als Fallback
|
|
- Vorschau einer Testmeldung auf das resultierende Divera247-Payload ohne Versand
|
|
- Browser-Konfigurations-API liefert weder Admin-Passwort-Hash noch Session-Secret aus
|
|
- ntfy-Ingress: Text, JSON, GET-Trigger und Aliase
|
|
- Gotify-Ingress: `POST /message`
|
|
- generischer Webhook-Ingress
|
|
- Bearer/Basic/Token-Authentifizierung für Ingress
|
|
- Divera247 v2 Client für Alarm/News/Event CRUD und Zusatzfunktionen sowie Pull
|
|
- Dry-Run, Dockerfile, Compose, Makefile und Linux-amd64-Build
|
|
|
|
## Geprüft
|
|
|
|
Alpha.5:
|
|
|
|
- `go test ./...`, `go vet ./...`, UI-Syntaxprüfung und Linux-amd64-Build ohne CGO erfolgreich.
|
|
- Unit-/Integrationstests für Outbox-Neustart, parallele Deduplizierung, Lease-Recovery und selektive Wiederholung.
|
|
- Lokale SMTP-Server: TLS/STARTTLS, fehlendes STARTTLS, Zertifikatsfehler, temporäre/permanente Fehler und MIME.
|
|
- Lokaler IMAP-Server: neue Nachrichten, Checkpoints, erneuter Abruf nach simuliertem Absturz, fehlende Zuordnung.
|
|
- Discord-Signaturen, Allowlist, Replay, CSRF, Login-Limit, Body-Limit und geschützte Metriken.
|
|
- Echter Chrome-Test: Login, SMTP-/Mail-Formulare, Zuordnung, Vorschau, CSRF-Speichern, Queue und Historie.
|
|
- Ausschließlich lokale Testdaten und Dry-Run; keine echten Provider-Nachrichten.
|
|
|
|
Provider-Erweiterung:
|
|
|
|
- `go test ./...` und `go vet ./...`: erfolgreich.
|
|
- `node scripts/check-ui.cjs`: JavaScript-Syntax und eindeutige DOM-IDs erfolgreich geprüft; kein Browser-Interaktionstest.
|
|
- Integration: Admin-Konfiguration inklusive Persistenz, Vorschau und authentifizierter ntfy-Eingang → Discord-Dry-Run.
|
|
- HTTP-Testserver: POST/Auth, Dry-Run ohne Netzwerk, Teilfehler, HTTP 429/500, Redirect-Blockierung und Secret-Redaktion.
|
|
- Bestehende Divera247-Tests weiterhin erfolgreich; ausschließlich lokale Testserver/Dry-Run genutzt.
|
|
|
|
Bisherige Snapshot-Prüfungen:
|
|
|
|
- `go test ./...`: erfolgreich
|
|
- `go vet ./...`: erfolgreich
|
|
- JavaScript-Syntax der eingebetteten WebUI: erfolgreich geprüft
|
|
- Regressionstest UCR-ID vs. globale User-ID: erfolgreich
|
|
- Mock-Integrationstest für mehrere v2-UCRs mit `cluster.consumer`, korrekten UCR-IDs und ohne v3-Zugriff: erfolgreich
|
|
- Regressionstest: v3 HTTP 403 wird nach einem Versuch kompakt gemeldet statt pro Einheit wiederholt
|
|
- lokaler Healthcheck: erfolgreich
|
|
- Admin-Login und Laden der neuen WebUI: erfolgreich
|
|
- Konfigurations-API: sensible interne Auth-Werte werden nicht ausgegeben
|
|
- Regelvorschau ntfy → Divera247 Alarm: erfolgreich
|
|
- ntfy/Gotify/Webhook → Divera247 Dry-Run aus dem vorherigen Snapshot weiterhin durch Unit-/Dispatcher-Tests abgedeckt
|
|
|
|
## Noch offen / nächste sinnvolle Schritte
|
|
|
|
Aktuelle Prioritäten: Retention/Archivierung, OAuth2/HTML-Mail/Quarantäne,
|
|
Secret-Verschlüsselung und automatisierte Backups/CI/Lasttests. Die nachfolgende
|
|
Liste stammt aus alpha.4; Queue, bcrypt, CSRF, Readiness und Basis-Metriken sind
|
|
inzwischen wie oben beschrieben umgesetzt.
|
|
|
|
1. Stammdaten persistent cachen und automatisch/periodisch aktualisieren.
|
|
2. Regelreihenfolge, Stop/Continue, Fallback- und Default-Regeln ausbauen.
|
|
3. Zusätzliche Divera247 Alarmfelder wie Alarmvorlage, Einsatznummer, Objekt, Anrufer, Patient und Rückmeldezeit als strukturierte UI-Felder ergänzen.
|
|
4. Divera247 v3 vollständig typisieren.
|
|
5. SQLite + Audit/Outbox/Retry/Deduplizierung.
|
|
6. Security-Härtung (Argon2id/bcrypt, CSRF, Secret-Verschlüsselung, Rate Limits).
|
|
7. Prometheus/Readiness/strukturierte Logs und CI.
|
|
|
|
## Wichtiger Hinweis
|
|
|
|
Es wurde **kein echter Alarm an Divera247** gesendet, da kein realer Accesskey vorliegt. Der Default bleibt `divera.dry_run=true`. Lesende Stammdaten-Aufrufe sind davon bewusst ausgenommen. Vor produktiver Alarmierung sollte mit einer Testeinheit und kontrollierten Empfängern verifiziert werden.
|