Authentifizierung mit Cookies ----------------------------- Zielsetzung: * Login nicht per HTTP Auth, sondern über eine hübsche Loginmaske. Warum? Nur weil es hübsch ist. Andere Vorteile sehe ich aktuell nicht. Ausloggen geht ja mittlerweile auch über HTTPBasicAuth. * Login soll in den Addons Multisite, NagVis und PNP4Nagios funktionieren. Umsetzung: * Die Passworte bleiben nach wie vor in der Datei htpasswd (verschlüsselt). Damit ist man auf jeden Fall kompatibel. * Wenn man auf index.py kommt (das Frameset) und hat noch kein Login-Cookie, dann kommt anstelle des Framesets eine Einloggemaske. Dort gibt man Name und Passwort ein und kann evtl. noch - wenn wir nett sind - seine Sprache einstellen. * Das eingetippte Passwort wird gegen die htpasswd-Datei geprüft. Dabei wird zumindest MD5 (verwendet WATO) und crypt (default von htpasswd) unterstützt. * Wenn das erfolgreich ist, wird ein Login-Cookie generiert. Dieses enthält folgende Daten im Klartext: - Loginname - Verfallszeit als Timestamp. Wenn das 0 ist heiÃt es "unendlich" Die Verfallszeit wird - in multisite.mk einstellbar - auf die Zukunft gesetzt, z.B. auf 60 Minuten. Das ganze ist pro Benutzeraccount einstellbar. Nach Ablauf der Zeit verfällt das Cookie. Diese beiden Angaben werden jetzt noch kombiniert mit dem verschlüsselten Passwort und einem Geheimnis, dass in der Datei etc/auth.secret gespeichert wird. Alle vier Werte werden durch Pipesymbole zusammengehängt, z.B. "harri|123909495|$1$090775$8M/9Eq3MlnP4yhafnc1ef/|L8jJLlk3ekFL" Dieser String wird jetzt mit MD5 gehäscht und daraus ein Cookie gebildet, z.B. "harri|123909495|89a3292c8a1496e864a4ba3d4080cad9". Dies ist dann der Inhalt des Cookies. * Das etc/auth.secret wird automatisch ausgewürfelt, wenn es noch nicht da ist. * Die WATO-Replikation muss auch das Secret mit replizieren, damit eine Anmeldung auch Remote immer gültig ist. * Der Pfad zu etc/auth.secret wird aus dem Pfad zur htpasswd-Datei gebildet. Diese ist Check_MK bekannt und steht in den Defaults in der Variable "htpasswd_file". Davon nimmt man den dirname. * Zum Ãberprüfen holt man Loginname und Verfallszeit aus dem Cookie. Ist die Zeit abgelaufen, wird das Cookie verworfen. Dann holt man sich das auth.secret und das verschlüsselte Passwort des Users und bildet erneut den Rohstring und häscht diesen. Wenn die MD5-Summe mit der im Cookie übereinstimmt darf man weiter. Wenn das Cookie eine Verfallszeit hat und *keine* Ajax-ID gesetzt ist, wird das Cookie automatisch erneuert. * Wenn man irgendeine Seite auÃer index.py aufruft und *kein korrektes* Cookie hat, dann wird man irgendwie weitergeleitet auf die Loginmaske. In dieser wird die eigentlich URL hidden mitgespeichert, so dass man nach dem Einloggen da weitermachen kann, wo man eigentlich hinwollte. * PNP und NagVis müssen ebenfalls in der Lage sein, ein Cookie zu überprüfen und zu erneuern. Dazu muss man den Code für das Ãberprüfen des Cookies auch in PHP schreiben. * Die Einstellung, ob man htpasswd oder Cookies macht, ist einfach: Wenn beim index.py bereits ein user bekannt ist (von Apache), nimmt man den. Ansonsten nimmt man die Cookies. * omd config bekommt eine Variable, die das steuert. Diese schaltet dann die Apache-Konfiguration für Check_MK, PNP und NagVis um. Wenn andere Lust haben (Thruk, etc.) können die sich auch dranhängen.