127 lines
3.2 KiB
Markdown
127 lines
3.2 KiB
Markdown
# Legacy Logging - Entwicklungsplan
|
|
|
|
## Ziel
|
|
|
|
Im Legacy-Projekt `_businessportal24.com` sollen taegliche Textlogs entstehen, damit aktive Benutzer, API-Frequenz und veroeffentlichte Pressemitteilungen bis zum Relaunch nachvollziehbar bleiben.
|
|
|
|
Die Logs werden bewusst ausserhalb von `web/` geschrieben:
|
|
|
|
```text
|
|
_businessportal24.com/log/activity/
|
|
```
|
|
|
|
## Log-Dateien
|
|
|
|
Pro Tag wird eine Datei je Ereignistyp erzeugt:
|
|
|
|
```text
|
|
login-success-YYYY-MM-DD.log
|
|
login-failed-YYYY-MM-DD.log
|
|
api-success-YYYY-MM-DD.log
|
|
api-failed-YYYY-MM-DD.log
|
|
publications-YYYY-MM-DD.log
|
|
```
|
|
|
|
Format ist JSON Lines: eine JSON-Struktur pro Zeile. Damit bleiben die Dateien einfache Textdateien, sind aber mit `jq`, `grep`/`rg` oder Skripten gut auswertbar.
|
|
|
|
## Erfasste Ereignisse
|
|
|
|
### Erfolgreicher direkter Login
|
|
|
|
Quelle:
|
|
|
|
- Frontend-Login ueber `plugins/PressePortalPlugin/modules/sfGuardAuth/actions/actions.class.php`
|
|
- Backend/Admin-Login ueber `plugins/PressePortalPlugin/modules/adminSfGuardAuth/actions/actions.class.php`
|
|
- Erfolg wird zentral in `apps/frontend/lib/myUser.class.php` und `apps/backend/lib/myUser.class.php` protokolliert.
|
|
|
|
Wichtige Felder:
|
|
|
|
- Zeitpunkt
|
|
- App (`frontend`/`backend`)
|
|
- Quelle (`login`/`admin`)
|
|
- User-ID
|
|
- Username
|
|
- Profil-E-Mail
|
|
- HTTP-Methode
|
|
- URI
|
|
- IP
|
|
- User-Agent
|
|
|
|
### Fehlgeschlagener direkter Login
|
|
|
|
Quelle:
|
|
|
|
- Frontend-Login-Aktion
|
|
- Backend/Admin-Login-Aktion
|
|
|
|
Wichtige Felder:
|
|
|
|
- Zeitpunkt
|
|
- Quelle (`login`/`admin`)
|
|
- Grund, aktuell `invalid_credentials`
|
|
- eingegebener Username
|
|
- HTTP-Metadaten
|
|
|
|
### Erfolgreiche API-Authentifizierung
|
|
|
|
Quelle:
|
|
|
|
- `plugins/PressePortalPlugin/lib/filters/ApiKeyGuardAuthFilter.class.php`
|
|
- Jeder API-Request mit gueltigem `X-ApiKey` wird einzeln protokolliert.
|
|
|
|
Wichtige Felder:
|
|
|
|
- Zeitpunkt
|
|
- Quelle `api`
|
|
- User-ID
|
|
- Username
|
|
- Profil-E-Mail
|
|
- HTTP-Methode
|
|
- URI
|
|
- IP
|
|
- User-Agent
|
|
|
|
### Fehlgeschlagene API-Authentifizierung
|
|
|
|
Quelle:
|
|
|
|
- `ApiKeyGuardAuthFilter`
|
|
|
|
Wichtige Felder:
|
|
|
|
- Zeitpunkt
|
|
- Quelle `api`
|
|
- Grund `missing_api_key` oder `invalid_api_key`
|
|
- uebermittelter API-Key
|
|
- HTTP-Metadaten
|
|
|
|
### Veroeffentlichungen von Pressemitteilungen
|
|
|
|
Quelle:
|
|
|
|
- Doctrine-Hook in `lib/model/doctrine/PressePortalPlugin/PressRelease.class.php`
|
|
- Protokolliert wird der Statuswechsel zu `published`.
|
|
|
|
Wichtige Felder:
|
|
|
|
- ausfuehrender Nutzer/Admin/API-User (`published_by`)
|
|
- Besitzer der Pressemitteilung (`owner`)
|
|
- Pressemitteilung-ID, Titel, Sprache, Status
|
|
- Firma/Pressemappe, falls vorhanden
|
|
- Pressekontakte, falls vorhanden
|
|
- HTTP-Metadaten
|
|
|
|
## Umsetzungsstrategie
|
|
|
|
1. Zentrale Logger-Klasse in `_businessportal24.com/lib/LegacyActivityLogger.class.php` anlegen.
|
|
2. Erfolgreiche Logins in den jeweiligen `myUser::signIn()`-Klassen loggen.
|
|
3. Fehlgeschlagene Login-POSTs in den Auth-Actions protokollieren.
|
|
4. API-Erfolg und API-Fehler im `ApiKeyGuardAuthFilter` protokollieren.
|
|
5. Veroeffentlichungen ueber `PressRelease::postSave()` bei Statuswechsel zu `published` protokollieren.
|
|
6. Syntaxpruefung fuer alle geaenderten PHP-Dateien ausfuehren.
|
|
|
|
## Deployment-Hinweise
|
|
|
|
Auf dem Live-Server muessen die geaenderten Dateien uebernommen werden. Das Log-Verzeichnis wird automatisch erstellt, sofern der PHP-Prozess Schreibrechte im Symfony-Log-Verzeichnis besitzt.
|
|
|
|
Wenn keine Dateien entstehen, zuerst die Schreibrechte von `_businessportal24.com/log/` pruefen.
|