Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/dbp15/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/dbp15/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/dbp15/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Datenbankpraktikum SS 2015 - D - Webclient

Der Webclient

Der von uns entwickelte Webclient setzt die bereits auf der Konsole ausführbaren Kommandos auf grafischer Ebene neu um. Hierzu benutzen wir eine Reihen an HTML Templates, die mit Hilfe von so genannten Moustaches bei jedem neuen Aufruf an neu gesendete Daten angepasst werden können während das generelle Layout der Seiten gleich bleibt. Momentan ist eine Login, Query sowie eine Logout und Error Page verfügbar.

Login

Auf der Login Page gibt der Nutzer zunächst seinen Username und sein Passwort für die Authentifizierung ein. Zurzeit handelt es sich hierbei jedoch nur um eine Pseudo-Authentifizierung da noch kein Verzeichnis für autorisierte Nutzer angelegt wurde. Des Weiteren kann der Nutzer auf dieser Seite eine von ihm gewünschte Bind-Adresse sowie einen Port angeben, über den die Verbindung laufen soll. Diese Angaben sind optional und werden ansonsten auf von uns festgelegte Standard-Parameter festgelegt. Diese Eingaben werden von uns auf ihre Validität überprüft. So werden ungültige Bind Adressen und Ports automatisch durch die Standards ersetzt und es wird darauf bestanden, dass sowohl Username als auch Passwort eingegeben werden müssen.

Cookies

Beim Einloggen wird außerdem ein Cookie erstellt, der dafür sorgt, dass der Nutzer sich während einer Sitzung nicht erneut anmelden muss und sich auf der Query Seite ausloggen kann, sobald er die Sitzung beenden möchte. Um festzustellen, ob der Nutzer bereits über einen Cookie verfügt oder sich neu anmelden muss um einen zu erstellen läuft folgendes ab: Nachdem das Programm erkannt hat, dass eine Post Action im Browser durchgeführt wurde, überprüft es, ob es im Header bereits Cookies gibt. Ist dies nicht der Fall, wird der Nutzer zur Login Seite umgeleitet. Wird ein Cookie gefunden, wird nun nachgeguckt, ob der betreffende Cookie zu unserem Programm gehört. Hierfür sucht man im so genannten CookieJar, das man aus allen vorhandenen Cookies bildet nachdem Namen „UosqlDB“. Existiert kein solcher Cookie, wird der Nutzer ebenfalls zur Login Seite geschickt. Existiert allerdings ein Cookie mit dem entsprechenden Namen, wird noch nachgeprüft, ob es sich um einen alten, und somit abgelaufenen Cookie handelt (was wiederum zu einem Login führt) oder ob es sich um eine aktuelle Session handelt und der Nutzer damit fortfahren kann. Um sicher zu stellen, dass die Cookies für die jeweiligen Sessions einzigartig sind, werden ihre Session-Strings auf den Namen der jeweiligen Nutzer gesetzt. Zu einem späteren Zeitpunkt sollte dies in eine zufällig generierte Zahlen- und/oder Buchstabenfolge umgeändert werden. Sollte es keinen gültigen Cookie geben, wird von uns mit den vom Nutzer übergebenen Daten eine Connection erstellt. Hierbei werden alle möglichen Fehler wie z.B. ein Connection Failure oder ein Network Error abgefangen und behandelt indem eine entsprechende Error Seite angezeigt wird.

Query

Auf dieser Query Seite ist es nun möglich, SQL Query-Strings einzugeben. Sollte die Eingabe grammatikalisch korrekt sein, so wird der Befehl ausgeführt und der Nutzer kann Datenbanken und Tabellen erstellen sowie Daten auslesen, soweit diese Befehle bereits von uns implementiert wurden. Die Rückgabe an Daten, die wir auf einen abgesendeten Query-String hin erhalten, wird von uns in einen lesbaren HTML String umgewandelt, der dann in unsere Template eingefügt wird um eine Tabelle auf der Query Seite anzuzeigen.

Zusätzlich nutzt unsere Implementierung einen Mutex-Guard, der sicherstellt, dass nicht mehr als ein Nutzer zu einem Zeitpunkt die Daten manipulieren kann. Dieser Guard lockt die Map, sobald ein Nutzer auf sie zugreift. Die Nutzung vieler Funktionen wurde durch die Einbindung von Nickel ermöglicht. Hierbei handelt es sich um ein Web Application Framework für Rust, dass es z. B. ermöglicht, auf Cookies zuzugreifen und sie zu manipulieren sowie auf der Query Seite abgesendete Strings auszulesen. Diesem Framework ist auch der Aufbau der main Methode geschuldet: diese ist aufgeteilt in mehrere Middlewares die Requests (die Daten, die sie bekommt) und Responses (die Daten, die wieder rausgeschickt werden) verwaltet. Diese Middlewares sind kategorisiert und die http Befehle post und get sowie utilize, der dafür sorgt, dass die betreffende Middleware vor jedem Request aufgerufen wird. In dieser wird bei uns das Cookie Management durchgeführt, damit der Nutzer nach Ablauf einer Session wieder zur Login-Seite geschickt wird auch wenn er das Fenster noch offen hat. Post behandelt bei uns das Login Management und wird jedes Mal angesteuert, wenn in unserem HTML Code target=“/login“ für einen Button oder ähnliches angegeben ist. Unsere main verfügt über zwei get-Middlewares. Die erste befasst sich mit dem Logout, also dem Trennen des Nutzers vom Server und wird bei „/logout“ angesteuert. Die zweite, und größere, behandelt unsere Query Seite und kümmert sich um das Senden von SQL Query-Strings sowie das Empfangen und Umschreiben der Ergebnisse unter Zuhilfenahme von Methoden, die den passenden HTML Code erstellen.


Autor: Lisa Konieczny
Gruppe: Stephanie Heyderich, Lisa Konieczny


Page last modified on September 24, 2015, at 02:18 PM