SimpleXMLRPCServer und Sessions

[droptix]

Möchte einen SimpleXMLRPC-Server über einen Webserver laufen lassen. Nun wird ja bei jeder Anfrage von einem XML-RPC-Client eine neue Verbindung aufgebaut und nach der Antwort wieder abgebaut.

Gibt es irgend eine (eingebaute) Möglichkeit, den Client wieder zu erkennen, also mit Sessions zu arbeiten? Oder müsste ich mir sowas selber basteln?

[veers]

Möchte einen SimpleXMLRPC-Server über einen Webserver laufen lassen. Nun wird ja bei jeder Anfrage von einem XML-RPC-Client eine neue Verbindung aufgebaut und nach der Antwort wieder abgebaut.

Gibt es irgend eine (eingebaute) Möglichkeit, den Client wieder zu erkennen, also mit Sessions zu arbeiten? Oder müsste ich mir sowas selber basteln?

Theoretisch, könntest du eine Session Id per Cookie speichern. Praktisch ist es wohl intelligenter diese als Parameter zu übergeben

[droptix]

Der Client für den SimpleXMRRPCServer ist kein Browser, sondern ein manuell geschriebener Client, an den ich später auch eine GUI hängen möchte. Dann kann ich keine Cookies speichern, richtig?

Nochmal zur ersten Frage: Gibt's eine fertige Lösung dafür? Ich bin doch sicher nicht der erste, der Sessions braucht.

[Rebecca]

Es gibt [mod]cookielib[/mod] und [mod]Cookie[/mod].

Hier hat mal wer einen XMLRPC-Client und Server gepostet, welcher Cookies verwendet: http://aspn.activestate.com/ASPN/Cookbo ... ipe/501148 (Erster google-Hit!)

[mitsuhiko]

HTTP Basic Auth

[droptix]

Es gibt [mod]cookielib[/mod] und [mod]Cookie[/mod].

Hier hat mal wer einen XMLRPC-Client und Server gepostet, welcher Cookies verwendet: http://aspn.activestate.com/ASPN/Cookbo ... ipe/501148 (Erster google-Hit!)

Wie gesagt, der Client ist nicht der Browser. Für mich sind Cookies ein reines Browser-Ding, oder liege ich da falsch? Eigentlich sind das auch nur Textdateien mit Plaintext-Daten...

HTTP Basic Auth

Das ist klar, aber ein und derselbe Benutzer könnte sich ja mehrfach zur gleichen Zeit anmelden. HTTP Basic Auth erkennt ja nur den Benutzer, richtig? Wenn den Account mehrere gleichzeitig benutzen können, dann braucht jeder Client eine eigene Session. Eine Session pro Benutzer reicht dann nicht aus... nicht dass sich die Clients in die Quere kommen können.

[Edit:] Wie ich auf Wikipedia gerade lese, werden Cookies im HTTP-Header hin- und hergeschickt. Das klingt gut und danach, wonach ich suche. D.h. ich muss sie nicht explizit als Argument einer XML-RPC-Methode mitschicken. Der SimpleXMLRPCServer muss die Cookie-Info aber aus dem Header der HTTP-Anfrage rauspopeln... Cookies in Browsern sind mir wohl einfach nur geläufiger als ein Bestandteil von HTTP.

[droptix]

Bei PHP sind Sessions auch dann möglich, wenn im Browser Cookies deaktiviert sind. Wie geht das eigentlich?

[Leonidas]

Bei PHP sind Sessions auch dann möglich, wenn im Browser Cookies deaktiviert sind. Wie geht das eigentlich?

Über Session-IDs, die in der URL via GET übertragen werden.

[jens]

Über Session-IDs, die in der URL via GET übertragen werden.

Was man eigentlich nie machen sollte

[audax]

Und genau aus dem Grund tut PHP es. Einfach aus Trotz.

[droptix]

Über Session-IDs, die in der URL via GET übertragen werden.

Das komische dabei ist, dass man die Session-ID nicht in seinen HTML-Code eingeflochten hat, aber der "gerenderte" HTML-Quelltext die dann trotzdem enthält. Also irgendwie hängt der PHP-Interpreter die GET-Variablen dann einfach an alle URLs und Formulare hinten dran.

Ging mir öfter auch schon so, und ich wusste nicht wieso.

[EnTeQuAk]

Du kannst den Sourcecode ausm ASPN (oben gepostet) ruhig verwenden. Cookies werden in einer Datei gespeichert, verwenden kannst du sie also auch in deinern Anwendung und nicht nur in Browsern. Schau dir dazu mal die Definition der Klasse CookieAuthXMLRPCTransport an, da wirds angewandt.


MfG EnTeQuAk