[Kevz]

Servus zusammen,

ich Arbeite derzeit an einer API bzw. versuche es... und suche dazu noch einige ansätze zur Umsetzung, und-/oder vielleicht auch Rat.


Es geht um folgendes:
Ich habe einen Server, dort sind Benutzerdaten in der MySQL- Datenbank gespeichert. Auf dem Server selbst werden/sollen Handlungen über den Client ausgeführt werden können.


Das Problem besteht dabei, daß ich ansätze für die Verbindung suche, zum aufbauen. Denn einerseits will ich Überprüfen ob der Client stets die aktuellen Daten vom Server holt, aber zugleich ob der Benutzer auch noch existiert, also Benutzerverifikation.
Dazu werden beim Login die Benutzerdaten (Benutzername u. Passwort) übermittelt. Soweit klappt das auch. Auch das verarbeiten vom Request. (wird als XML- ausgegeben)

Ich habe es derzeit so gehandhabt, daß nachdem der Benutzer sich eingeloggt hat, eine Art "Sicherheitscode" nur noch von Nutzen ist. Sprich, der Benutzer muss nicht immer wieder seine Benutzerdaten übermitteln. (klappt auch soweit)
Aber es stellt sich dabei die Frage, ob es nicht verkehrt ist, jedes mal aufs erneute eine Anfrage an den Server zu schicken, mit dem "Sicherheitscode". (mit diesem werden auch die aktuellen Benutzerdaten vom Server geholt)


WIE gehe ich nun weiter an das ganze am besten ran?, also was den Verbindungsaufbau angeht. Hatte bereits in die Richtung "SOAP" und "fsocken" gedacht. Ich arbeite derzeit auf der Basis von cURL und kann eig. nicht klagen.. Zumal die Ausgabe vom Server nur XML ist, auf die Anfragen vom Client.


€dit:
Zu spät diesen Link gesehen:
API für Applikation


Sorry.

[Jann Hendrik]

Ist dir mit dem link schon geholfen?

[Kevz]

Einen schönen Guten morgen,

bin dem nicht wirklich näher gekommen, als zuvor. Es geht immer noch lediglich um die Geschichte mit dem immer wieder erneuten schicken einer Anfrage und wie man es am besten handhabt.
Denn ich könnte mir vorstellen, daß jedes Anfragen vom Client aus evtl. doch sehr in die Performance vom Server geht. Der Server gibt ja lediglich eine Ausgabe des Requests in Form einer XML- Ausgabe.

Mit dem "Sicherheitscode" konnte ich zumindest schonmal das Übermitteln der Benutzerdaten sehr vereinfachen und leichter verarbeten, um nicht immer wieder diese Daten zu schicken.


Nur bin ich eben etwas skeptisch was die Übertragung angeht, mit cURL, oder auch file_get_contents. Ich lasse mich in dessen bezug gerne eines besseren belehren, was die handlung angeht. :)

[Jann Hendrik]

Dort in den thread war ja auch die Alternative via GET oder POST genannt worden.

[Kevz]

Die Übermittlung mit welchen Typ ich das tue ist ja nicht das Problem. Es geht ja um die Verbindung. Es wird alles lediglich mit GET ausgeführt, aber der Verbindungstyp spielt eben eine rolle, wie bereits oben erwähnt.

[robo47]

was genau versteht du unter verbindungstyp ? Geht es dir um fsockopen vs curl ? Weil ich seh da erstmal keinen unterschied ob du händisch den request via fsockopen machst, file_get_contents, curl oder ne http-klasse wie Zend_Http_Client, Snoopy, PEAR_HTTP oder wenn du soap / xml-rpc / rest nutzt eine fertige klasse für das ganze wie Soap (Extension von php), Zend_Soap, Zend_Xmlrpc, Zend_REST.

Beim Zend-Framework findest du da meines wissens nach für die meisten technologien sowohl was für die Server-Seite, als auch für die Client-Seite (z.b. auch dann für die unittests und so)

[Kevz]

Genau, um die Verbindung geht es mir.

Aber wie sieht es denn bei dem Verbindungsaufbau aus, ist es nicht aufwendiger eine Verbindung immer wieder anzufragen, oder zumindest herzustellen, um Daten zu holen, als eine dauerhafte Verbindung zu haben? Mir gehts dabei auch um die last - wobei ja nur wenige XML Daten immer geholt werden..

[robo47]

Solange die API über http läuft, was ein zustandsloses protokol ist, bedeutet jede anfrage = 1 request, es gibt da keine möglichkeit ne verbindung aufzubauen und mehr als einen request zu schicken so wie man das vielleicht bei mysql und co kennt, unschön aber möglich wäre es nur von deinem server aus zu erlauben mehrere requests direkt als 1 zu formulieren, dann bekommt man aber mischmasch als antwort zurück und die gegenseite muss das dann auch wieder verarbeiten können, davon würde ich eher abraten.

[Kevz]

Also dann so handhaben, wie bisher?

Denn imho lasse ich die Benutzer via API Einloggen, erhalten nachdem Login einen Sicherheitscode der dann solang fortlaufend ist, wie diese auch Eingeloggt sind. Und für alle Handlungen schicke ich imho via API halt eine Anfrage - der request ist ja derzeit nur die XML- Ausgabe, die der Client selbst verarbeitet.

[robo47]

Überleg dir aber wie du "eingeloggt" spezifierst bei einem zustandslosen protokol meldet der user sich nämlich nicht zwangsläufig ab, du brauchst also sowas wie z.b. ne lebenszeit oder ähnliches.

[Kevz]

Da hast mich nun gut getroffen. *lach*


Ich hatte vor bei der Anmeldung eine Art "Session" im System zu hinterlegen. Denn wenn der Benutzer eine Anfrage an den Server schickt, kann ich direkt Überprüfen wann die letzte Aktion von ihm gewesen war..


Aber selbst an der Session muss ich ja irgendwie wieder den Benutzer daran identifizieren. Und selbst das würde ja nur wieder gehen, wenn ich z.B. die Benutzer- Id mit an die Anfrage schicke, oder so. Wobei dadurch natürlich andere Benutzer das verändern könnten.. Und mit einem Sicherheitscode wäre es, wie ich ja derzeit mache, am besten gelöst. Aber ob es dauerhaft eine Lösung ist? =/


Hast mich aber jetzt gut ins grübeln wieder gebracht. ;)

[robo47]

Session für die API ist eher unpraktikabel, weil für php die üblichen methoden zur erkennung der session ist: cookie oder parameter in der url, beides bei einer api nicht wirklich praktikabel da soap und co üblicherweise an FESTE URLS gehen und sich die clients auch keine transaktions-übergreifenden Daten merken wie Cookies.

Mit Transaktion mein ich hier nicht einen einzelnen request sondern das was zusammengefasst ist. Sprich wenn auf der anderen Seite ein php-script steckt das irgendwelche daten aus der API abruft besteht die transaktion z.b. aus login ->token erhalten und dann vielleicht 2-3 abfragen von daten mit dem token. In so einem Fall kann man problemlos einen token generieren der z.b. 5 minuten gültig ist.

Wenn deine API sich eher an persistent laufende clients richtet, kann man ja auch eine art "refresh" vorraussetzen der einen token für weitere X minuten gültig markiert oder halt auch gleich sagen der Token ist X stunden gültig, danach muss der client sich halt nen neuen holen, wobei das schon wieder etwas die unter umständen gewonnene sicherheit die ein temporärer token bietet untergräbt.

Wenn man sieht der aufwand mit den tokens ist zu groß, kann man notfalls auch den Overhead in kauf nehmen bei jedem request username + password mitzuschicken.

[Kevz]

*grml* - Okay.. gut. Aber vielen Dank schon einmal.

Ich denke, dann werde ich wohl ehr den Overhead in dem falle in Kauf nehmen.. Denn damit ist ja letztenendes die Sicherheit gegeben, daß ich somit das mit der "Lebenszeit" handhaben kann. Zumal der Aufwand nicht so groß ist... und für die API nicht wirklich relevant ist...


Aber vielen Dank, schon einmal - hat mir einiges geholfen.

[robo47]

Zitat von Kevz

Denn damit ist ja letztenendes die Sicherheit gegeben

Ich hab das eher so gesehen, dass es mit einem Token in gewissenen Szenarien sicherer sein kann.

Wenn ich beispielweise einen token abfange, ist der ja dann nur XX minuten (mal keine refresh-möglichkeit vorrausgesetzt und keine möglichkeit in der API benutzerdaten ohne die alten zu ändern) gültig, wenn ich login-daten abfangen -> unendlich gültig, alles machbar.


Wenn man da dann halt noch mehr sicherheit was den "Weg" angeht will, muss man sich halt wenn möglich für SSL entscheiden.

[Kevz]

Alles klar.


Dann hat sich das soweit erst einmal alles geklärt, werde mich nochmal ausgiebig damit beschäftigen.

[Basti]

Hi.

Um die PHP-internen Session-Funktionen zu nutzen kann man die Session-ID durchaus auch z.B. in einem XML-Knoten übergeben und dann per session_id() setzen.

Falls Du sicherstellen kannst, dass die Requests vom Client alle quasi nacheinander kommen, wäre es am sichersten, Du gibst bei jedem Request einen einmaligen Hash zurück, den Du in der Session speicherst und den der Client beim nächsten Request übergeben muss und der eben nur für einen Request und für eine kleine Zeitspanne gültig ist.

Du würdest also ganz normal die Session-Id ausgeben und Dir bei jedem Request übergeben lassen und zusätzlich noch dieses Sicherheitsschlüssel, der nach jedem Request verfällt.

Bastian

[Kevz]

Servus zusammen,

und noch einmal auf ein neues. (:


Das ganze hat mich über die ganze Zeit nun nicht in ruhe gelassen und habe mir viele Gedanken zu gemacht und habe mich letztenendes doch für die "token"- Variante entschieden.

Ich habe es vorerst mit viel skepsis betrachtet und erst letztendes gesehen, daß es nicht anderes ist, als wenn ich einen "Sicherheitskey" verschicken, oder zumindest hergebe, oder etwas anderes.


Ich will es ein bisschen Übersichtlicher beschreiben, um verstehen zu geben, was eig. nun erstmal das Problem ist.

Ich habe eine API die auf den Server ist, von niemand zugreifbar => auf diese API lässt sich mit der Client- API zugreifen, kein SSL- o.Ä. (ich weiss, wäre zwar besser, aber mir gehts imho erstmal um das Grundgestell) => die Client- API kann auf der eigentlichen API am Server REQUESTS absetzen (also HTTP GET oder POST anfragen)

..wenn ich aber nun sogenannte "tokens" erstelle, oder zumindest bereitstelle - stellen diese also eine Art "session cookie" da? Sprich die Cookies sind nur für eine gewisse Zeit gültig. Angenommen ich würde die Cookies auch als eine Art "timeout" Variante nutzen, um einfach zu Überprüfen, wann die letzte Aktion war etc., um den Client nicht dauerhaft aufrecht zu erhalten.



Ich wollte das vorab klären. Denn ich scheine Hoffnung zu haben, daß es doch noch klappt, wie es vorab eig. auch gewünscht war. (: Habe sowas ähnliches auch in der API von Facebook gesehen..