Welche authentifizierungs Lib

Django, Flask, Bottle, WSGI, CGI…
TDO
User
Beiträge: 25
Registriert: Montag 10. Juli 2006, 19:49
Kontaktdaten:

Welche authentifizierungs Lib

Beitragvon TDO » Mittwoch 22. April 2009, 23:36

Hi,

ich bastel grad an ner Website mit Werkzeug... nun bin ich an dem Punkt wo ich ein Login-System brauche... ich meine mal gelesen zu haben das es wohl schon fertige libs gibt welche einem die Benutzerverwaltung und Erstellung bissle abnehmen.

Wollte mal fragen ob ich da recht gehoert hab bzw. welche Ihr mir empfehlen koenntet..

Danke und gruessle
TDO
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Donnerstag 23. April 2009, 00:42

User-Model mit Secure-Session-Cookie. Einfach mal im werkzeug-Source nachlesen (oder in der Doku).

Gruß
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Donnerstag 23. April 2009, 07:36

Darüber hinaus gibt es auch AuthKit und Barrel.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Beitragvon lunar » Donnerstag 23. April 2009, 09:57

Und repoze.what ...
TDO
User
Beiträge: 25
Registriert: Montag 10. Juli 2006, 19:49
Kontaktdaten:

Beitragvon TDO » Donnerstag 23. April 2009, 16:11

und mit welcher habt ihr schon gearbeitet? bzw. als gut befunden?
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Donnerstag 23. April 2009, 16:36

Oben erwähntes, ganz einfach deswegen, weil ich da wenigsten Doku lesen musste... aber halt ein bisschen was selbst implementieren.

Damals mit werkzeug ging das so: In die WSGI-Klasse folgendes in die dispatch-Methode:

Code: Alles auswählen

if request.cookies.should_save:
        cookies = request.cookies.serialize()
        response.set_cookie('session', cookies, httponly=True)
        # safe cookie


Wobei `self.cookies` (`request.cookies`) eine Instanz der `werkzeug.contrib.securecookie.SecureCookie`-Klasse ist.

Die Überprüfung ob man eingeloggt ist hab ich dann so gemacht:

Code: Alles auswählen

def authenticate_user(request):
    try:
        name, password = request.cookies.get('session', (None, None))
    except ValueError, e:
        name, password = None, None
    if name and password:
        user = User.query.filter_by(name=name).first()
        if user and user.password == password:
            return user


Wobei `User` das User-Model ist (SQLAlchemy-Model).
lunar

Beitragvon lunar » Donnerstag 23. April 2009, 17:44

Mmmh, sonderlich gut ist das aber nicht, da bei jedem Request ein Datenbankzugriff und ein möglicherweise teurer (falls Hashing involviert ist) Passwortvergleich stattfindet. Bei einem Cookie, dessen Werte durch einen serverseitigen Schlüssel gesichert sind, muss man das Passwort nicht erneut prüfen, weil die Existenz des Cookies bzw. der Benutzerkennung im Cookie an sich als Beweis der Identität ausreicht. Schließlich kann man den Keks dank des serverseitigen Schlüssels nicht fälschen oder manipulieren.

Sinnvoller wäre es daher, einfach nur Benutzername, Anmeldedatum (für zeitlich limitierte Sitzungen) und evtl. IP-Adresse im Cookie zu speichern und zu sichern.

Vor allem aber hast du damit nur die Authentifizierung, nicht aber die Authorisierung erledigt, es sei denn, deiner Anwendung genügt es zu wissen, dass der Nutzer nicht anonym ist. Berechtigungen, Rollen und Gruppen musst du bei deinem Ansatz ebenfalls manuell implementieren, was der größere Teil der Arbeit ist.

Ich persönlich nutze repoze.what-quickstart. Damit ist eine WSGI-Middleware, die eine Webform-Authentifzierung gegen eine SQLAlchemy-Benutzerklasse mit sicherem Cookie für die Session bereitstellt, mit einem Funktionsaufruf aufgesetzt. Berechtigungen und Gruppen gibts für lau dazu, außerdem integriert sich das Ganze wunderbar in Pylons.

Bei Interesse kann ich dir morgen auch gerne eine kleine Beispielanwendung dazu zusammenprogrammieren.
TDO
User
Beiträge: 25
Registriert: Montag 10. Juli 2006, 19:49
Kontaktdaten:

Beitragvon TDO » Donnerstag 23. April 2009, 18:01

also interesse wäre meinerseits da... auch wenn ich wohl nicht gemeint war ;)
lunar

Beitragvon lunar » Donnerstag 23. April 2009, 18:11

Natürlich warst du gemeint, wer denn sonst? Du hast schließlich gefragt :)

Allerdings habe ich heute keine Zeit mehr dafür, du musst dich bis morgen Abend gedulden.
TDO
User
Beiträge: 25
Registriert: Montag 10. Juli 2006, 19:49
Kontaktdaten:

Beitragvon TDO » Donnerstag 23. April 2009, 18:43

hehe kein Thema .. dachte du hast Dauerbaustelle gemeint weil dir ja seine Implementierung nicht gefallen hat.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Donnerstag 23. April 2009, 19:39

lunar hat geschrieben:Mmmh, sonderlich gut ist das aber nicht, da bei jedem Request ein Datenbankzugriff und ein möglicherweise teurer (falls Hashing involviert ist) Passwortvergleich stattfindet.

Hashing ist natürlich nicht nötig; ich hoffe doch, dass jeder, der Passwörter speichert, dies in bereits gehashter Form tut...

lunar hat geschrieben: Bei einem Cookie, dessen Werte durch einen serverseitigen Schlüssel gesichert sind, muss man das Passwort nicht erneut prüfen, weil die Existenz des Cookies bzw. der Benutzerkennung im Cookie an sich als Beweis der Identität ausreicht. Schließlich kann man den Keks dank des serverseitigen Schlüssels nicht fälschen oder manipulieren.

Hm, ich weiß grade garnicht wie der Cookie erzeugt wird. Müsste ich mir bei Gelegenheit mal ansehen.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Donnerstag 23. April 2009, 19:45

Hab mir das mal angeguckt. Der Keks wird durch (Pseudocode!) `base64(secretkey, passwort, username))` erzeugt. Da der Secret-Key wirklich secret ist, müsste ich das nicht mehr überprüfen, weil der Key ja nie rausgegeben wird und somit Manipulation unmöglich ist. Aber für den Fall, dass jemand zufällig eine passende Zeichenkette (welche das Ganze sinnvoll entschlüsselt) erzeugt....*ausred*
lunar

Beitragvon lunar » Freitag 24. April 2009, 09:35

Dauerbaustelle hat geschrieben:
lunar hat geschrieben:Mmmh, sonderlich gut ist das aber nicht, da bei jedem Request ein Datenbankzugriff und ein möglicherweise teurer (falls Hashing involviert ist) Passwortvergleich stattfindet.

Hashing ist natürlich nicht nötig; ich hoffe doch, dass jeder, der Passwörter speichert, dies in bereits gehashter Form tut...

Bei der Anmeldung aber wird das Passwort meist im Klartext übertragen, daher wäre es denkbar gewesen, dass das Passwort im Klartext im sicheren Cookie abgelegt wird. Wenn die Werte des Cookies nicht nur durch einen Hash gesichert, sondern wirklich verschlüsselt sind, wäre das nicht unbedingt ein Nachteil gewesen.
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Freitag 24. April 2009, 14:10

Bei dem Beispiel kommen die Passwörter als Hash.
nemomuk
User
Beiträge: 862
Registriert: Dienstag 6. November 2007, 21:49

Beitragvon nemomuk » Freitag 24. April 2009, 16:56

Ist es eigentlich sinnvoll das Passwort auf Clientseite per JavaScript schon zu hashen und dann per AJAX an den Server zu schicken? Hätte ja eigentlich den Vorteil, dass das Passwort nicht Plaintext duch's Netz geht (wenn man kein SSL hat).

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder