gitmedia/presseportale
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
presseportale/dev/archive/legacy_logging/ENTWICKLUNGSPLAN.md
Kevin Adametz 6a4c4d8837 docs: dev-Doku für den Live-Betrieb neu sortiert — Archiv + Betrieb + Roadmap 
Das System ist seit 20.07.2026 live; die dev-Doku spiegelt jetzt den
Betriebszustand statt der Release-Vorbereitung:

- dev/betrieb/: Deploy-Runbook (neu: §10 Betrieb nach Go-Live mit
  SFTP-Deploy-Checkliste inkl. queue:restart-Pflicht und den
  Betriebs-Erkenntnissen der Go-Live-Woche), Legacy-API-Parität, Umami.
- dev/roadmap.md: offene Nachlauf-Punkte (Go-Live-Mails, Merge nach main,
  Stripe-Test-Artefakte, Key-Rotation, Alt-System-Abschaltung) und
  Ideen-Backlog.
- dev/archive/: abgeschlossene Phasen — Migration-2026-Planung,
  Cutover-Runbook (mit Erledigt-Vermerk), Release-Plan/QA-Checkliste,
  Optimierungsphasen, Frontend-Konzepte + Responsive-Audits vom 16.07.,
  Altsystem-Reste.
- dev/README.md als Wegweiser; gitignore-Pfad der SQL-Dumps mitgezogen
  (dev/archive/migration-2026/sql/ bleibt untracked, ebenso dev/migration/
  und dev/api/).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-21 07:52:38 +00:00

3.2 KiB
Raw Blame History

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.