Sven Rautenberg: Errorlog erweitern

Beitrag lesen

Moin!

»» Aber deine Logfunktion erfordert zwingend einen zweiten Parameter, der ein Objekt mit der Eigenschaft "error" sein muss, und greift außerdem auf mysqli_connect_error() zu.

Nein, der zweite Parameter erwartet lediglich die Variable für $_dbConnect, das auch nur, weil ich diese nicht in der Funktion als global deklarieren wollte.

Diese Variable wird aber in der Funktion verwendet, und es wird ohne weitere Checks einfach davon ausgegangen, dass sie ein Objekt mit Eigenschaft "error" ist.

Abgesehen davon zeigt dein Logfile-Auszug ja, dass die Fehler allesamt ohne Datenbankmeldung ablaufen. Ich ziehe sehr stark in Zweifel, dass überhaupt mal ein Datenbankfehler auf diese Weise geloggt wird.

Auf der anderen Seite sieht man sehr schön, dass die Behandlung des DB-Zugriffs bei dir noch verbesserungswürdig ist, denn sonst würde ein Fall wie "Zuviele DB-Connections" keine PHP-Fehlermeldungskaskade erzeugen, sondern rechtzeitig abbrechen und Status 500 auswerfen.

Die Notice mit unbekannter Variable ist auch heilbar.

Und wie du selbst siehst: Der Zugriff auf mysqli_error() funktioniert nicht, wenn kein MySQLi-Objekt in der Log-Funktion verfügbar ist.

Abgesehen davon sind mir zwei Dinge in Bezug auf die ErrorLogFile-Konstante aufgefallen:

1. Du übergibst die Konstante immer - außer an einer Stelle. Warum ist sie dann in der Funktion optional gemacht und als Default-Wert mit dieser Konstanten ausgestattet?

2. Was erwartest du hier?

  ini_set('error_log', 'error/error_log.inc.php');   ## Error-Log  
  define('ErrorLogFile', ini_get('error_log'));      ## Error-Log-Pfad

Wenn ich mal deine Dateizugriffslogik hernehme: Sollte ini_set() NICHT erfolgreich den Logdatei-Pfad setzen können, wird dein eigenes Error-Logging in das Logziel geschrieben, das von der Installation vorgesehen ist.

error_log enthält aber nicht zwingend einen Datei- bzw. Pfadnamen. Und da dein eigener Aufruf von error_log() ja ohnehin fest die Optionen für das Logging in eine Datei enthält, ist das Resultat dieses Konstruktes hier potentiell böse.

Ich würde vorschlagen: Definition einer Konstanten mit dem Error-Log-Dateinamen, und zwar als fixer String. Dann ini_set() des error_log-Wertes. Entfernung des optionalen dritten Parameters aus der Logfunktion, und Nutzung der Konstanten als Dateiname im Aufruf von error_log().

Weiterhin: Die DB-Fehler gehören nicht in deiner Logfunktion abgefragt, sondern im Bedarfsfall von der Applikation als Logmeldung ausgegeben. An vielen Stellen, an denen eine Logmeldung erzeugt wird, ist gar kein DB-Zugriff erfolgt - und an den Stellen, wo er erfolgt, sollte die Fehlerbehandlung auch explizit greifen, und Errorlogging gehört nun mal dazu.

Aktuell sieht meine index.php so aus, allerdings bastel ich noch dran.

Ja, ich erinnere mich - diese komische Filterfunktion, die einfach mal pauschal alles, was irgendwie "böse" aussieht, in der URL rausfischt, kommt mir extrem bekannt vor - wir hatten schon mal diskutiert, dass das absolut nicht gerechtfertigt und notwendig ist.

Interessant übrigens auch deine Redirect-Funktion. Warum steht die ganz am Ende, nachdem für den Request schon wahnsinnig viel Arbeit geleistet wurde, und prüft dann einfach nur die aufgerufene Domain? Sowas gehört ganz an den Anfang des Skripts, ohne Ausgabe irgendwelcher HTML-Inhalte (wobei der Standard empfiehlt, aber nicht zwingend vorschreibt, dass der Seiteninhalt einer Redirect-Antwort einen Link auf das Redirect-Ziel enthält.

Was mir hingegen als Verbesserung deines Loggings eingefallen ist: Der Referrer fehlt. Nur mit dieser Info weißt du, wo der fehlerhafte Link aufzufinden ist, dessen Ergebnis du da gerade loggst.

- Sven Rautenberg