In einem früheren Blog-Beitrag haben wir Ihnen gezeigt, wie Sie mit dem 4D REST Server loslegen können. Wir haben Sie durch verschiedene CRUD-Operationen mit Postman geführt und Sie auf die vollständige REST-Dokumentation hingewiesen. In diesem Blog-Beitrag erklären wir Ihnen, wie Sessions in 4D funktionieren. So können Sie ein Session-basiertes Authentifizierungssystem mit dem 4D REST Server aufbauen.
4D Rest Sessions
Wenn Sie ein Authentifizierungssystem aufbauen möchten, ist ein Session-basiertes System genau das Richtige für Sie!
Verbindungen zum 4D REST Server sind sitzungsbasiert. Das bedeutet, dass der 4D Server bei der ersten Anfrage des Clients eine Sitzung erstellt und ein Sitzungs-Cookie (WASID4D) an ihn zurückschickt. Bei allen nachfolgenden Anfragen muss der Client dieses Session-Cookie im Header der Anfrage zurücksenden. Dies steht im Gegensatz zur Token-basierten Authentifizierung, bei der keine Sitzung auf der Serverseite, sondern auf dem Client gespeichert wird.
Konfigurieren Sie den REST-Server
Jetzt, da wir wissen, wie Sitzungen gehandhabt werden, können wir weitermachen. Bevor wir loslegen können, müssen Sie den 4D REST Server starten und konfigurieren. Bitte lesen Sie dazu diesen Blogbeitrag oder das Dokumentationszentrum, bevor Sie fortfahren.
Zur REST-Authentifizierungsmethode
The On REST Authentication Mit der Datenbankmethode können Sie individuell steuern, wie REST Sitzungen in 4D geöffnet werden. Wenn eine Anfrage zum Öffnen einer REST-Sitzung eingeht, werden die Verbindungskennungen(z. B. Benutzername und Passwort) im Header der Anfrage angegeben. Die Datenbankmethode On REST Authentication wird aufgerufen, damit Sie diese Identifikatoren auswerten und True (Sitzungseröffnung akzeptiert) oder False (Sitzungseröffnung abgelehnt) zurückgeben können.
Hinweis: Mit dieser Datenbankmethode können Sie zwar Ihre eigene Zugriffskontrolle auf die Datenbank programmieren, aber der Zugriff kann auch über eine 4D Benutzergruppe eingeschränkt werden. Wenn Sie die Datenbank freigeben, wählen Sie auf der Registerkarte Datenbankeinstellungen > Web > REST-Ressourcen die Gruppe aus, die Zugriff hat. In diesem Blogbeitrag können Sie Ihr Gedächtnis auffrischen.
Eine Sitzung öffnen
Um das Öffnen einer Sitzung zu veranschaulichen, stellen wir uns ein Anmeldeformular mit einem Login und einem Passwort vor. Wir werden Postman verwenden, um die Anmeldedaten in den Kopfzeilen der POST-Anforderung zu senden. Um eine Sitzung in Ihrer 4D Anwendung über REST zu öffnen, verwenden Sie $directory/login:
Kehren wir zu 4D zurück und sehen wir uns an, was hier vor sich geht.
Wie Sie sehen können, erhält die Datenbankmethode vier Parameter:
- $1 für den Benutzernamen,
- $2 für das Passwort,
- $3 gibt True zurück, wenn das Passwort gehasht ist, und False, wenn es nicht gehasht ist,
- $4 enthält die IP-Adresse des Aufrufers.
Hinweis: In der realen Welt sollten Passwörter gehasht und nicht im Klartext gesendet werden. Um ein gehashtes Passwort zu senden, können Sie den Parameter hashed-password-4D anstelle von password-4D verwenden. Dieses Codebeispiel zeigt Ihnen, wie Sie vorgehen müssen.
Sobald die Anfrage eingegangen ist, eröffnet der Server eine Sitzung und sendet ein Sitzungs-Cookie an den Client zurück (WASID4D):
Wie können wir nun, da unsere Sitzung erstellt wurde, ihre ID in nachfolgenden HTTP-Anfragen zurückgeben?
Moment mal … warum müssen wir das überhaupt tun?
Sitzungsverwaltung
HTTP ist ein „zustandsloses“ Protokoll … jedes Mal, wenn ein Client eine Verbindung zu einer Webseite aufbaut, öffnet er eine separate Verbindung zum Webserver. Der Server führt keine Aufzeichnungen über frühere Client-Anfragen. Stellen Sie sich vor, Tausende von Clients stellen eine Verbindung zum Server her, woher soll er wissen, welche Sitzung die Ihre ist? An dieser Stelle kommt die Sitzungsnummer ins Spiel. Durch diesen Austausch von Sitzungskennungen wird der Status aufrechterhalten. Was bedeutet das genau? Nun, es bedeutet, dass Sie, um dieselbe Sitzung wiederverwenden zu können, sicherstellen müssen, dass alle nachfolgenden REST-Anfragen die Sitzungs-ID in den„Cookie„-Header der Anfrage aufnehmen. Andernfalls wird eine neue Sitzung eröffnet (und eine neue Sitzung bedeutet eine neue Lizenz).
Beispiel
Die Art und Weise, wie Sitzungen zu behandeln sind, hängt von Ihrem HTTP-Client ab. Nehmen wir an, wir befinden uns in einem Kontext, in dem Anfragen über den Befehl HTTP Request abgewickelt werden.
Um die Sitzungs-ID in die Kopfzeile aufzunehmen, müssen wir sie zunächst finden. Das ist einfach! Wir wissen, dass die Sitzung einen WASID4D-Schlüssel hat, also müssen wir nur nach diesem Schlüssel in den Werten des Headers mit dem Befehl Find in array suchen:
Find in array($headerValues; "WASID4D@")
Sobald wir ihn gefunden haben, können wir ihn extrahieren:
$start:=Position("WASID4D";$cookie)
$end :=Position(";";$cookie)
$uuid := Substring($cookie;$start;$end-$start)Die $uuid enthält die Sitzungs-ID, die in allen nachfolgenden Anfragen gesendet wird. Das vollständige Beispiel finden Sie hier.
Kontrolle der Sitzungszeitüberschreitung
Standardmäßig beträgt der Timeout für die Inaktivität der Sitzung 60 Minuten und kann nicht unterschritten werden. Sie können jedoch die Timeout-Länge mit dem Wert des Parameters„session-4D-length“ erhöhen, der in POST-Headern mit der Methode $directory/login übergeben werden kann.
Eine weitere Sache
4D Server verfügt über eine Session, in der die Auswahl von Entitäten auf der Grundlage früherer Abfragen oder Bestellbefehle gespeichert wird. Wenn also der nächste „Bereich“ (oder Chunk) von Daten benötigt wird, muss nicht erneut abgefragt/bestellt werden, sondern es muss einfach der nächste Datensatz gesendet werden. Dieser Mechanismus ermöglicht die Verwendung von Transaktionen, pessimistischen Sperren und mehr.
Was kommt als Nächstes?
Der REST Server wurde mit 4D v18 stark erweitert, und weitere Funktionen sind für die Zukunft geplant. In der Zwischenzeit werden wir Sie weiterhin mit Beispielen und praktischen Anwendungsfällen versorgen. Beteiligen Sie sich an der Diskussion im 4D Forum.