[PHP] Loginsystem - Therotische Frage

[[jacky]]

Hallo,

ich baue gerade ein relativ komplexes Loginsystem.
Da es sehr viele Administrator - "Werkzeuge" gibt, möchte ich gerne loggen, das ein User tut.
Wie sollte ich dabei vorgehen?
Soll ich eine Tabelle nehmen, die ca wie folgt aussieht:

fk_user_id   |  action

und dann dort die Userid mit der Aktion reinspeichern?
Oder soll ich nur die Adresse (also Url) speichern, darüber erfährt man ja eigentlich auch, was ein User macht.
Oder soll ich im Quellcode bestimmte "IDs" festlegen, so z.b. wenn ein Formular fehlerfrei losgeschickt wurde, dass dann dort z.b. folgendes steht:

$log_user_action_ID = 'user erfolgreich editiert'

und dann das speichern ... aber das wäre dann nciht sehr dynamisch, da ich auf jeder Seite, wo man sich einloggen kann bzw die man als eingeloggter besuchen kann eine solche ID vergeben müsste ...

Weitere Frage:

Soll ich dann immer einen neuen Datensatz speichern oder das als serialisiertes Array speichern: also immer auslesen, in Array umwandeln, dann eine Aktion hinzufügen und dann wieder serialisieren und speichern?

Danke im voraus!

[steffenk]

das kann man nicht verallgemeinern, es kommt darauf an, was Du loggen willst.
Ich habe in der Regel bei allen Tabellen ein Feld uid, das anzeigt, wer den Datensatz geändert / gelöscht hat. Das ist sehr rudimentär.
Etwas kompletter ist eine Logtabelle, die die Aktion, Zeit und User festhält.

[[jacky]]

Hm, es gibt in meinem Adminmenü folgende Menüpunkte:

- Benutzergruppen erstellen / editieren / löschen
- User anlegen / editieren / löschen
- Rechte anlegen / editieren / löschen
- Datenbankbackup erstellen

So, das will ich halt alles loggen.

So, wenn ich einen internen Bereich definieren will, mache ich das halt einfach über die Methode hasRight:

PHP-Code:

<?php
// hier halt so die config..
$cfg = array();
...

// instanz erstellen:
$um = new admin($cfg);

// und dann halt einfach schauen, ob der user einbestimmtes recht hat (kann ja im adminmenü erstellt werden):
if(!$um->hasRight('recht_name'))
   die('kein zugriff');

//... hier dann der rest des scripts...
?>

So, und so ungefähr sieht dasnn ein interner Bereich aus. Nun will ich halt loggen, wo er rumsurft etc.
Also sollte ich wahrscheinlich einfach sowas machen:

insert into logtabelle (time, userid, url) values ( time(), $_SESSION['userid'], $_SERVER['SCRIPT_NAME'] );

joa, wär das so nicht ganz gut?

[steffenk]

naja, Du kannst loggen was Du willst, solang die Information auch wirklich nützlich ist. Es fallen halt auch viele Daten an, ich weiss ja auch nicht, wieviele User es gibt.
Das mit $_SERVER['SCRIPT_NAME'] kannst Du Dir sparen, wenn Du je nach Deinem Aufbau
in jeder Seite am Anfang in eine Session-Routine springst, die Dir Session öffnet, logt, etc.

[[jacky]]

hm, ok ... eventuell ist das unwichtig zu loggen ...
wie wäre es nun mit den vordefinierten Aktionen im Adminmenü!?
Soll ich da einfach bestimmte site_ids vergeben (im Quellcode an entsprechender Seite in ein Superglobales array speichern) und dann am ende der Seite einach diesen Wert in die DB sichern?

[giv]

ein log ist primär dazu da, ihn in bestimmten fällen auszuwerten. an deiner stelle würde ich mir überlegen, in welchen fällen du was evtl. wissen möchtest und wie du das dann visualisierst (z.B. html generierst oder einfach mit nem texteditor ne logdatei anschaust). dann sollte eigentlich ziemlich klar sein, welche der vielen möglichkeiten, die du dir überlegt hast, bezüglich der realisierung, man wählen sollte - nämlich die variante, mit der du am einfachsten deine auswertungen machen kannst.

normalerweise solltest du mit dem tripel (zeit, user, aktion) als eintrag auskommen. wenn du eine detailierte und flexible auswertung anstrebst, dann ist es sinnvoll, dies in einer datenbanktabelle noch weiter aufzuspannen, etwa (zeit, user, aktionstyp, message) - so könnte man etwa noch leicht erfolgreiche von nicht erfolgreichen aktionen filtern.

[DSB]

Mir würde die Information das ein User eine bestimmte Aktion ausgelöst hat nicht reichen.
Wenn dann will ich ja auch wissen, was er gemacht hat.
Deshalb sind meine Logtabellen so aufgebaut:
ID | UserID | ID des geänderten Objektes| Aktion | alterWert | neuerWert | Timestamp der Aktion

Eine Routine prüft bei einer Änderungen welche Felder eines Datensatzes sich geändert haben und trägt nur die veränderten Werte ein. So hat man eine aussagekräftige Historie (Strasse des Kundendatensatzes mit der ID 521 von "Brummweg" auf "Bremer Strasse" geändert...).
Die Aktion wird per Funktionsaufruf übergeben und enthält "Neuanlage, Änderung, usw"
Die Information wo jemand rumgesurft ist halte ich für überflüssig, da sie die DB nur unnötig anschwellen lassen.
Wichtig ist doch die Aktionen festzuhalten, die eine Veränderung des bestehenden Datenbestands verursachen. Und genau hier will man später wissen: wer hat wann was geändert.

[[jacky]]

stimmt eigentlich
Naja, dann habe ich also so eine function (in etwa:

PHP-Code:

function log($pars)
{
  $sql = 'UPDATE logtable SET';
  foreach($pars as $k=>$v) {
    $sql .= ' '.$k.' = "'.$v.",
  }
  // ^
  //  |
  // bzw auch insert into ...
} 


und dann übergebe ich bei "news schreiben" z.b.:

PHP-Code:

if($_POST['sent'])
  // ...
  // wenn kein fehler auftrat:
  $this->log( array('userid' => $_SESSION['userid'], 
                          'time' => time(),
                          'aktion' => 'write_news',
                          'newsid' => mysql_last_id(), 
                          'ip' => $_SERVER['REMOTE_ADDR'], 
                          'url' => $_SERVER['REQUEST'], // oder wie auch immer das nochma heißt^^
                         ));
} 


bzw wenn jmd news ändert:

PHP-Code:

if($_POST['sent'])
  // ...
  // wenn kein fehler auftrat:
  $this->log( array('userid' => $_SESSION['userid'], 
                          'time' => time(),
                          'aktion' => 'edit_news',
                          'newsid' => $_POST['change_id'], 
                          'ip' => $_SERVER['REMOTE_ADDR'], 
                          'url' => $_SERVER['REQUEST'], // oder wie auch immer das nochma heißt^^
                         ));
} 


verstehe ich das so ungefähr richtig?

[DSB]

Ja genau so meinte ich das.
Da die Spalten in der Tabelle ja feststehen würde ich nicht bei jedem Aufruf ein Array bilden sondern eine eine feste Parameterliste an die Funktion übergeben.
Dann wäre der Aufruf auch kürzer.

Ich selbst arbeite mit Objekten und übergebe der Logfunktion das alte und das neue Objekt.
Dort vergleiche ich Eigenschaft für Eigenschaft und trage nur die veränderten Eigenschaften in die Logtabelle ein. So ists nochmal universaler.

[[jacky]]

stimmt, du hast recht.
Ich arbeite zwar auch mit Klassen (bzw eher mit einer Klasse, in der für jede Aktion (news löschen/editieren/anlegen) eine Funktion gibt ...
Hast du dann für jede Aktion eine Klasse oder wie?

Außerdem, wie vergleicht man das denn gescheit? Also ich meine, du hast doch nicht ale alten Werte in einer Klasse und alle neuen Werte in einer oder doch!?

[DSB]

Üblicherweise werden Änderungen ja über ein POST-Formular gemacht.
Vor einer Änderung habe ich den momentan Stand ja in der DB (Änderung) oder wenn es keinen entsprechenden Eintrag gibt, dann ist es eine Neuanlage.

Den alten Stand hole ich mir aus der DB und mit den POST-Eingaben bilde ich ein zweites Objekt.
Die Funktion rufe ich dann auf mit log($aktion,$altes_objekt,$neues_objekt);

In der Funktion kann man beliebige Objekte mittels get_object_vars analysieren und dann Wert für Wert vergleichen. Ich weiß aber nicht, ob das auch tatsächlich Sinn bei dir macht.
Bei mir ist jedes Datenbankobjekt eben ein Objekt und deshalb bietet sich das bei mir an.

[giv]

im allgemeinen tendiere ich dazu, logs in textdateien abzulegen. selten schreibt man für die ansicht von logs eine aufwändiges html interface oder ähnliches. am häufigsten schaue ich mir logs eh in rohform durch bzw. beachtet man gewisse kleinigkeiten bezüglich konsequent genutzter trennzeichen, dann bietet die unix konsole mächtige tools, um gezielt solche files auszuwerten.

oft werte ich logs auch nicht auf der produktionsmaschine aus, auf der der webserver läuft, muss sie daher in der regel erst noch verschieben/kopieren. mit ner db hab ich halt im allgemeinen erstmal mehr aufwand, an die daten ranzukommen. die häufigkeit, mit der man sich mit den logs beschäftigt muss, rechtfertigt den einsatz einer db oft nicht - es sei denn, das programm selbst nutzt die logs.

[steffenk]

Das kann man doch halten wie man will - ich benutze logs meist in der Admin-Umgebung, und da sind Tabellen leichter zu handhaben. Und ein Dump ist schnell gemacht (ja womit nur ? )

Daniels Lösung eignet sich zum Beispiel auch wunderbar dazu, solche Änderungen wieder rückgängig zu machen - gerade bei CMS-Systemen ist das ein sehr nützliches Feature.

Wenn man Logs in eine Klasse auslagert, kann man schnell und unkompliziert die Logs in DB / Dateien / Mail oder sonstwohin umleiten.

[DSB]

Ich benutze lieber DB-Tabellen, da man sich so über Filter auch schöne Historien ansehen kann.
Man kann sich die Ausgabe z.B. nach Aktionstyp oder User filtern lassen und bekommt so viel schneller einen Überblick als mit Textfiles.
Außerdem kann man durch einen einfachen Query alle veralteten Einträge aus der DB löschen. Da finde ich das Handling dann wieder viel einfacher als mit Textdateien.

Aber Du hast schon recht giv - man muss immer Aufwand und Nutzen gegeneinander abwägen. Da bei meinen Applikationen aber eh alles in Datenbankobjekten gekapselt ist und ich bereits universale Routinen und Schnittstellen habe, ist die Verwaltung eines Logs für mich mit wenigen Zeilen Code erledigt und in dem Fall weniger aufwändig als Textlogfiles.
Das mag bei anderen Anwendungen natürlich anders aussehen.