Verbessertes Logfile

[MarkusR]

Gerade bei Datenbankfehlern sind die Logeinträge fast unleserlich, daher habe ich nun folgendes erprobt:
1.) Bemerkungsfeld erlaubt nun 16384 statt 255 Zeichen -> Aufteilung auf mehrere Einträge entfällt
2.) Bemerkungsfeld wird nun ohne htmlspecialchars() ausgegeben
3.) So kann ich nun formatierte Informationen eintragen, also mit Zeilenschaltungen, Fettdruck, Links etc.
4.) für Datenbankfehler habe ich noch ein backtrace hinzugefügt, so dass man den Auslöser des Fehlers schneller findet

Neben der Verbesserung für Entwickler möchte ich zukünftig Links zu beabeiteten Artikeln (statt nur Nummer: Titel), zu Benutzern und anderen bearbeiteten Dingen dort anbieten. Und auch die lapidaren "CSRF check failed." könnten viel mehr Informationen preisgeben. Ist ja eh nur für den Admin/Superuser interessant...

[hscha]

Hallo Markus,
ist das schon verfügbar? Ich finde das oberpraktisch!
Grüße von Horst

[MarkusR]

Nicht wirklich.

Das Umstellen der Datenbank-Tabelle für größere Einträge und Ausgabe als HTML ist simpel.
Es müssen aber sämtliche - oder zumindest die relevanten - in zahllosen Dateien verstreuten Logausgaben überarbeitet werden, das ist die größte Arbeit.

Ggf. gibt es eine unkomplizierte Version für die Datenbankabfragen.

[hscha]

Ok. Ich bin gespannt

[MarkusR]

Aber Du könntest bzw. ALLE könnten auch ein Feedback geben, wo Du den Eindruck hast, dass die Logfile-Einträge wenig hilfreich sind bzw. es viel Recherche benötigt, die ausgeführte Aktion nachvollziehen zu können.

Das ist natürlich speziell dann wichtig, wenn man einen Stapel Redakteure hat, die alles mögliche ausführen...

[hscha]

Hilfreich wären aus meiner Sicht ausführlichere Infos bei folgenden Fällen:

delete article -
create... -
edit... - jeweils außer der Artikelnr. und Titel auch die Rubrik

placeholders save: außer Namen und ID auch der Name des Template

CSRF check failed - falls es mehr Infos gäbe, wäre das wg. der Fehlerquelle hilfreich

Außerdem wie du oben schreibst das Zusammenlegen mehrerer Meldungen bei database error.

Mehr fällt mir in meinem Logfile nicht auf...
Grüße von Horst

[MarkusR]

Erstellen und Ändern von Artikeln wird ja beides als save article geloggt, hierzu habe ich schon ein paar Links gebaut (Ansehen im Frontend, Artikel direkt bearbeiten, Rubrik aufrufen)

Screenshot 2026-01-27 211829.png

Placeholder save hat auch einen direkten Link

Was sollte bei gelöschten (und somit wiederherstellbaren) Artikeln angeboten werden?

Bei "CSRF check failed." steht ja immer dabei, was schief gelaufen ist, da jedes Token einer bestimmten Aktion zugeordnet ist.

Screenshot 2026-01-27 212404.png

[hscha]

Erstellen und Ändern von Artikeln wird ja beides als save article geloggt, hierzu habe ich schon ein paar Links gebaut (Ansehen im Frontend, Artikel direkt bearbeiten, Rubrik aufrufen)

Screenshot 2026-01-27 211829.png

Placeholder save hat auch einen direkten Link

Was sollte bei gelöschten (und somit wiederherstellbaren) Artikeln angeboten werden?

Bei "CSRF check failed." steht ja immer dabei, was schief gelaufen ist, da jedes Token einer bestimmten Aktion zugeordnet ist.

Screenshot 2026-01-27 212404.png

Die Links zum Bearbeiten sehen sehr brauchbar aus! Bei gelöschten Artikeln wäre der Link zum Wiederherstellen sicher sehr praktisch...

[MarkusR]

Da hast Du wohl recht.
Nicht ganz trivial, weil dabei auch die aktive Rubrik gewechselt werden muss, es gibt also bisher keinen nutzbaren Link.

Aber ich denke sowieso, dass der Lösch- bzw. Wiederherstellungsprozess etwas wortkarg ist und denke mal über den Ablauf nach...

Und in meinen Notizen habe ich gerade gefunden, dass ich da eine Vorschau realisieren wollte...

[MarkusR]

Hm, bei "CSRF check failed." bin ich nun am Grübeln, welche Infos da hilfreich sein könnten.

Wie gesagt, der Ort ist ja klar, weil immer nur ein bestimmtes Token für eine bestimmte Aktion genutzt und ausgewertet wird.
Auch die Ursache ist klar, nämlich das Senden von Formulardaten, die nicht vom dafür vorgesehenen Formular stammen, also möglicherweise ein Hack-Versuch.
Oder das mehrfache Absenden eines Formulars bzw. Rückspringen im Browserverlauf.

Was könnte da denn noch interessant sein?
Die gesendeten Daten?

Da diese CSRF Checks schnell das Log überlaufen lassen, denke ich über eine Auslagerung in ein separates Log nach, insbesondere wenn noch die gesendeten Daten gespeichert werden sollen...

[hscha]

Ich habe keine Vorstellung davon, welche Daten bei "CSRF check failed." anfallen... Gut wäre es, wenn man nachvollziehen könnte, warum das Login von Webseiten-Usern mit dieser Fehlermeldung abbricht. Das kommt auf meiner Website öfter vor...

[MarkusR]

Tja, genau das kriegt man aber nicht raus.
Es ist nur klar, dass der Sicherheitstoken nicht gepasst hat.
Die Gründe habe ich ja oben genannt.

Ich schaffe es nur diese Meldung zu provozieren, wenn ich bei einem fehlerhaften Login (falsche Anmeldedaten) einen Reload durchführe.

Eine Möglichkeit gibt es aber: Wenn es das gleiche Formular auf der Seite zweimal gibt, also das eigentliche Login-Formular von member.php und noch ein zusätzliches, das das gleiche Token schreibt, das dann aber für das erste Formular nicht mehr passt.

Passiert bei mir immer, wenn ich ein Kontaktformular (mod_form) standardmäßig auf jeder Seite habe und dann dort ein zusätzliches Formular (ebenfalls mod_form) nutze...

Allerdings kann ich Dir nicht erklären, warum das dann Probleme bereitet, weil es eigentlich auch mit mehreren Tokens für die gleiche Aktion funktionieren sollte...

Mittels debugging könnte man rauskriegen, ob beide Tokens vorhanden sind...
.
.

[hscha]

Ah, so ist das! ...dann muss ich das doppelte-Login-Formular verhindern... - hat natürlich erstmal nix mit dem Logfile zu tun, ist aber ein wertvoller Hinweis.
Danke!

[MarkusR]

Theoretisch dürfte es keine Probleme geben, da es nicht unüblich ist, dass sich bis zu 1000 Tokens in der Session sammeln und unabhängig voneinander nutzbar sein sollten.

Praktisch hat sich aber bei mir die Nutzung von zwei Tokens für die gleiche Aktion auf einer Seite als Fehlerursache herausgestellt.

[MarkusR]

ACHTUNG: Habe gerade nochmal rekapituliert und festgestellt, dass die Probleme bei mir von zwei Captchas auf einer Seite ausgingen. Das funktioniert nicht!

CSRF-Tokens sollten funktionieren.

Bitte kläre doch mal, ob die User tatsächlich Probleme beim Einloggen haben.

Falls es da keine Erkenntnisse gibt, dann sind es vermutlich Hacker oder Bots, die eben versuchen diesen Schutz zu umgehen. Somit ist das Auftreten der Meldungen kein Fehler sondern ein gutes Zeichen!

Sorry für den Denkfehler!