paos

Hallo zusammen,

ich stehe vor der Aufgabe einen Web-Service zu entwickeln und habe darin bisher (fast) keine Erfahrung. Für die Entwicklung habe ich mich für NuSOAP entschieden, allerdings noch nicht letztendlich festgelegt.

Der Service soll einen Login mit Email und Passwort anbieten; Angemeldete User sollen dann Zugriff bestimmte Services/Funktionen erhalten.

Mich beschäftgt aktuell die Frage des Session Handlings. Wie funktioniert das generell bei Web-Services? Die Clients sollen nicht zwangsläufg Browser sein und können zB. nichts mit Cookies anfangen.

Aktuell schwebt mir folgender Ablauf vor:

1. Client-Login mit User und Passwort
2. Login-Funktion auf Server wird ausgeführt und eine Session-ID wird generiert, Session-ID wird in Datenbank geschrieben
3. Antwort von Server an Client inkl. generierter Session-ID
...
N. Client-Funktionsaufruf inkl. Session-ID
N+1. Funktionsaufruf überprüft anhand Session-ID Befugnis
N+2. Antwort von Server...

ALternativ kann man natürlich auch immer die Anmeldeparamter mitsenden und so vor Ausführung der Funktion die Berechtigung prüfen.

Wie ist die übliche Vorgehensweise? Kennt jmd. vielleicht ein Beispiel?

Beste Grüße, Marco

Mister Ad

Chriz

Welchen Vorteil hat dann die Session? HTTP-Authentifizierung macht es ja auch ohne: einfach die Zugangsdaten immer mit im Header senden. Einen Logout muss es dann auch nicht mehr geben, du brauchst keinen Garbage-Collector, du hast keinen Session-Timeout, du kannst User sofort aussperren, .. und dank SSL ist es dann auch weniger problematisch, wenn du dauernd das Passwort hin und her schickst. Muss aber zugeben, dass ich nicht mehr auf dem neuesten Stand dahingehend bin.

__________________
"Nuschel ich?" - "Was?"

G.Schuster

Was nicht heißt, dass das eine gute Idee ist.
Bedenkt man, dass sicherlich 90% der User ein Passwort für nahezu alle Seiten/sonstiges verwenden sollte man Passwörter - auch mit SSL - so selten wie möglich transferieren.

Hm?

Den kann man beliebig einstellen, erhöhen, verringern...also kein Argument.

Mit z.B. einem DB-SessionHandler kein Problem.

Was ich recht praktisch finde (und auch erst so umgesetzt habe): Login mit Zugangsdaten, Session zuteilen, Client sendet die Session dann bei jedem Request als SOAP-Header mit.
Ich weiß jetzt nicht, wie das bei nuSoap ist, bei der PHP-Ext. jedenfalls wird für einen mitgesendeten Header eine Methode des gleichen Namens aufgerufen, bevor die eigentliche Methode ausgeführt wird.
Du könntest dir allgemein zum Thema WebService-Auth mal die WSS-Spezifikationen und das WSO-Framework (wso2.com) ansehen.
Es gab hier übrigens erst kürzlich einen Thread zu dem Thema

__________________
actra.development - Schwabstr. 2 - 70825 Münchingen
www.actra.de/velopment/ - eMail: php.de@actra.de
Zend Certified Engineer for PHP5

Chriz

Was ist daran unverstaendlich? Wenn eine Session geoeffnet wird, sollte sie auch wieder geschlossen werden. Selbst ein Webservice bekommt das grade noch hin, oder?

Das hab ich ja auch nicht gesagt. Ich meine nur, dass - fuer mich - die Summe der TODOs gegen Session-Handling spricht. Der einzige Nachteil den ich sehen kann ist, wie du schon angesprochen hast, das mehrmalige Verschicken des Passworts, was ich aber dank SSL als kein Problem ansehe.

Aber sicher, die Klasse waere ohne SSL dann nicht wirklich fuer den Einsatz zu empfehlen.

__________________
"Nuschel ich?" - "Was?"

G.Schuster

Ich konnte dir nur einfach nicht folgen.
Was in meinen Augen allerdings noch _für_ Sessions spricht ist die Tatsache, _dass_ Sessions ablaufen.
D.h. gesniffte Zugangsdaten sind so lange gültig, bis sie geändert werden (sofern man den Standard-Weg geht), Sessions hingegen bringen einem Angreifer idR einige Stunden später schon nichts mehr.

Aber um bei deinem Ansatz zu bleiben und wieder auf die Diskussion aus dem letzten Thread zu kommen - sofern die PWs bei jedem Request mittels eines anderen Hashs (Nonce/Timestamp, siehe WSS UsernameToken) bekommen, die nach einer Benutzung gesperrt werden dürfte das auch relativ OK sein.

__________________
actra.development - Schwabstr. 2 - 70825 Münchingen
www.actra.de/velopment/ - eMail: php.de@actra.de
Zend Certified Engineer for PHP5

paos

Wie ich sehe, ist die Antwort auf meine Frage gar nicht so einfach wie ich sie mir erhofft habe.

Ich bin auch der Meinung, dass Passwörter nur so oft wie eben wirklich notwendig übertragen werden sollten. Zudem würde diese Lösung ja weitere unnötige Datebankabfragen nach sich ziehen. Ein Session-Handling finde ich da auch praktischer.

Allerdings bin ich mir immer noch unsicher, wie man das jetzt wirklich realisiert. Gibt es zu diesem Thema ein kleines Tutorial oder ein Code-Snipplet.

G.Schuster

Prinzipiell läuft das SessionHandling wie mit einer normalen Web-Applikation.
Einziger Unterschied ist die Art, wie die ID übertragen wird.
Entweder, du übergibst sie jedem Methodenaufruf z.B. als ersten Parameter - unschön, Fehleranfällig (vergessen); oder eben per Header.
Beispiele zum Senden von Headern findest du in der Doku: http://de.php.net/manual/de/soapheader.soapheader.php
Serverseitig muss dann in deiner Klasse einfach eine Methode existieren, die genauso heißt wie der Header, die wird dann automatisch aufgerufen, bevor die eigentlich gewünschte Methode ausgeführt wird (bezogen auf PHP-Ext, nuSOAP kenne ich nicht).

__________________
actra.development - Schwabstr. 2 - 70825 Münchingen
www.actra.de/velopment/ - eMail: php.de@actra.de
Zend Certified Engineer for PHP5

paos

Ok, danke für die Antworten! Ich werde wohl beim ersten beschriebenen Weg bleiben und das ggfls. später noch erweitern.