presseportale/dev/legacy_logging/ENTWICKLUNGSPLAN.md

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:

_businessportal24.com/log/activity/

Log-Dateien

Pro Tag wird eine Datei je Ereignistyp erzeugt:

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.