[python-users] twisted xmlrpc/jsonrpc authentifizierung und Session-Verwaltung

[Thomas Renard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo zusammen,

irgendwie verzweifle ich völlig bei dem
Twisted-AUthentifizierungs-Mechanismus. Entweder ich entwickle gerade
etwas, was es nicht geben darf, Twisted ist völlig ungeeignet dazu
(?), oder ich bin nicht mehr in der Lage, mit der neuen Google-Engine
irgendeine vernünftige Antwort aus dem Netz zu ziehen...

Egal, ich beschreibe einfach mal, was ich vorhabe, vielleicht hat ja
irgendwer ne Idee dazu:

Ich baue eine eine Webanwendung, die von der Client-Seite aus über
jsonrpc auf einen Twisted-Server zugreift. Je nach (un-)angemeldetem
User möchte ich, daß der Twisted-Server unterschiedliche JSONRPC-Klassen
anzieht und der Webanwendung somit einen unterschiedlichen
Funktions/Methodensatz zur Verfügung stellt:

class AnonymousResource(jsonrpc.JSONRPC):
    """Methods for anonymous users"""

    def __init__(self):
	pass

    def jsonrpc_login(self, username, password):
        """Hier soll das Login-Geraffel ablaufen. Für einen
unangemeldeten Anwender die einzige Funktion"""

class UserResource(jsonrpc.JSONRPC):
    """Hier tauchen alle methoden auf, die ein User aufrufen darf"""

    ...

    def logout(self):
        """klar, abmelden muß man sich auch mal"""

class AdminResource(UserResource):
    """und hier alle zusätzlichen methoden für den Admin, die
       der User nicht machen darf"""
    def __init__(self):
	UserResource.__init__(self)

Der obige Aufbau ist etwas starr, ermöglicht aber hoffentlich bei
zukünftigen Erweiterungen so gut wie möglich weitere Module.

So, wie ich das verstanden habe, sollte Twisted mit cred irgendwie in
der Lage sein, je nach Zustand einer Session eine dieser drei Resourcen
zur Verfügung zu stellen.

Die Beispiele, die ich überhaupt gefunden habe, verwenden
HTTPAuthWrapper, verlangen also eine User/Pass-Abfrage per HTTP Header.

Was ich hier aber habe, soll auf der Client-Seite eine Form haben, die
beim Drücken auf den Feuerknopf einen jsonrpc-Aufruf machen soll und
daraufhin z. B. vom Server einen Cookie gesetzt bekommt mit der Session
ID (besser noch: er liefert die ID zurück, und bei weiteren AUfrufen
wird die ID wieder im Funktionsaufruf mitgegeben, ggf. ist nämlich mein
JS-Konstrukt zu blöde, Cookies zu verarbeiten oder mit dem
XMLHTTPRequest abzuschicken).

Die Infrastruktur für die Session-Verwaltung ist da
(SQLAlchemy-Datenbank mit einem Session-Element, einem User-Element, in
dem auch definiert ist, ob der Anwender User oder Admin ist - eigentlich
ein Integer, 1->User, 10->Admin).

Außerdem: ein normaler jsonrpc-unauthentifizierter Handshake
Server<->Client funktioniert bereits ;-)

Jetzt die Frage: Wie bekommt man das in eine funktionierende
cred-Struktur? Ich benötige einen Realm, der eine der drei oberen
Classes liefert, aber die Portal/Cred-Geschichte ist mir ein völliges
Rätsel.

Noch ne dumme Frage: Wenn es da ne Lösung für gibt, wie verhält sich da
ein Caching (immerhin ist bei jedem Aufruf die Session samt User aus der
Datenbank zu holen, das wäre ja praktisch, wenn der Twisted-Server das
im Cache halten könnte).

Im Augenblick arbeite ich mit twisted.web und txjsonrpc. Ich möchte den
Library-Wust möglichst gering halten, damit das, was rauskommt auch noch
bei möglichst vielen läuft. Also möchte ich Nevow oder ähnliches meiden.
Pure twisted sozusagen. Wenn wer ein Beispiel hat, was mit xmlrpc
funktioniert, bin ich auch glücklich (txjsonrpc ist nahezu vom xmlrpc
geklont). Unittests mit Twisted und Nose scheine ich auch schon im Griff
zu haben - mal schauen, wie das mit nem Portal aussieht...

Wenns denn mal funktioniert, habe ich vielleicht was für nen Vortrag
(Fettere Javascript-Client-Applikationen in Python gecoded: pyjamas -
http://pyjs.org - das ist nämlich der coole Aspekt bei meiner Anwendung).

Jeder Hinweis macht mich glücklicher ;-)

erstmal danke für alle Bemühungen

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkssAQwACgkQhrhMPFWiJKoFdACfTfhPhtIx338iOAmuUrS8dXaw
8qgAoJcl8mKVzuABiWNJUYKFFRX4ofyc
=70sX
-----END PGP SIGNATURE-----