Computerorientierte Mathematik

Ergänzungen und Hinweise

• Bei der Veränderung der Nutzerdaten kann euer Server vom Client unvollständige Daten bekommen. Soll nur der Name geändert werden, so schickt der Client für alle anderen Daten leere Strings (nicht null!).

  Das ist unter anderem der Fall, wenn ihr auf unserer Client Seite Felder leer lasst.

• Das in AccountClientRequest enthaltene Objekt MyPasswordAuthentication hat eine besondere Bedeutung:

  username

  identifiziert den Datensatz, auf dem operiert werden soll,

  password

  ist nur dann relevant, wenn ein neues Passwort gesetzt werden soll (SIGN_UP, CHANGE_PASSWORD)

• Wenn ein Client eine MyPasswordAuthentication gesendet hat, dann wartet er auf eine AccountServerResponse, die

  response.isPasswordAutheticationResponse() und

  response.isOkay()

  erfüllen muss. Erst danach geht die eigentliche AccountClientRequest raus.

Ziel der letzten Programmieraufgabe der CoMa ist das Schreiben eines CoMa-Account-Servers. Zur Verwaltung von Webaccounts zählt es, dass die Nutzer ihre essentiellen Daten selbst aktuell halten können. Zu jedem Account-Inhaber werden die folgenden persönlichen Daten gehalten:

• Name,
• Vorname,
• Geschlecht,
• Nutzer-ID,
• Passwort,
• E-Mail Adresse.

Nicht betrachtet wird die Sicherheitsproblematik bei der Datenübertragung. Insbesondere wird mit dem Passwort immer in unverschlüsselter Form gearbeitet.

Funktionalität

Der Account-Server hat Zugriff auf die Inhaberdaten über die Nutzer-ID, das ist das einzige Datum welches für jeden Inhaber garantiert eindeutig ist. Die Daten sollt Ihr natürlich in Eurem AVL-Baum, der inzwischen mit parallelen Zugriffen umgehen kann, halten.

Zu dem Server kann eine Verbindung hergestellt werden, über die Daten und Kommandos ausgetauscht werden. Eine Verbindung wird jedoch vom Server nur akzepiert, wenn sich der Benutzer durch sein korrektes Passwort autorisieren kann. Das heißt, der Server erwartet zunächst ein Objekt in dem der Client seine Nutzer-ID und sein Passwort mitteilt. Danach kann der Benutzer alle seine Daten abfragen und bis auf die Nutzer-ID verändern beziehungsweise seinen Account löschen. Einzige Ausnahmen sind das Anlegen eines neuen Accounts und das Anfordern des eigenen Passworts, diese sind auch ohne Autorisierung möglich. Die Passwortanforderung soll zum Verschicken des Passworts an die aktuelle E-Mail Adresse des Nutzers führen. Das simulieren wir durch das Anhängen der E-Mail Adresse und des Passwortes an eine Datei.

Parallelität

Der Server darf natürlich nicht durch eine einzelne Anfrage blockiert werden. Das heißt, für jede eintreffende Anfrage wird ein neuer Thread, der die Abwicklung übernimmt, geöffnet. Zu dokumentarischen Zwecken soll das Hauptprogramm ein Fenster öffnen, in dem alle Anfragen und Antworten protokolliert werden.

Das Hauptprogramm soll alle Parameter der ServersSocket und, wie schon in der letzten Aufgabe, alle aktiven Verbindungen anzeigen.

Hilfe

Damit Ihr zum Testen Eures Servers nicht auch noch einen Client programmmieren müsst, stellen wir Euch diesen zur Verfügung. Das ist aber nicht nur als Hilfe zu verstehen, sondern auch als Einschränkung. Denn Eurer Server muss mit dem von uns gestellten Client kommunizieren können.

Ihr könnt unseren Client über diese Web-Seite aufforden, Anfragen an Euren Server zu senden. Dazu muss der Client wissen, unter welcher Adresse und an welchem Port Eurer Server lauscht. Diese Daten erhaltet Ihr von Eurer ServerSocket. Da mehrere von Euch sich unter Umständen einen Rechner teilen, sollt Ihr den Port für die ServerSocket nicht vorgeben. Wenn Ihr als Port 0 angebt, so wird ein freier Port gewählt, den Ihr danach abfragen könnt. So kann es zu keinen Kollisionen verschiedener Sockets kommen. Das Hauptprogramm soll laut Aufgabenstellung in jedem Fall alle Parameter Eurer ServerSocket ausgeben!

Die für Euch notwendigen Daten erhaltet Ihr hier:

• der Client als gzip tar oder als zip Archiv,
• 50.000 Account Daten als gzip oder als zip Datei und
• die Dokumentation der serialisierten Klassen.

Euer Programm muss auch einen AVL-Baum mit allen 50.000 Accounts bearbeiten können. Die Syntax der Account Datei ist eigentlich selbsterklärend. Das einzige was völlig unlesbar ist sind die Passwörter und die 0 / 1 steht für weiblich / männlich.

Das Protokoll

Wie schon gesagt muss Euer Server mit unserem Client kommuniziren können. Dazu müsst Ihr natürlich wissen, wie die Kommunikation auszusehen hat, d.h. wie lautet das Protokoll, an das sich sowohl der Server als auch der Client zu halten haben.

Die Kommunikation zwischen Server und Client erfolgt über einen ObjectInputStream und einen ObjectOutputStream. Server und Client tauschen also Objekte aus. Dabei muss das Objekt, welches ein Client an den Server schickt entweder vom Typ MyPasswordAuthentication oder vom Typ AccountClientRequest sein. Umgekehrt schickt der Server immer ein Objekt vom Typ AccountServerResponse .

Nur wenn der Ausdruck "obj instanceof AccountClientRequest" wahr ist, soll der Server versuchen, die im Objekt obj enthaltene Anforderung zu bedienen. Das setzt bei einigen Anforderungen voraus, dass sich der Client zuvor durch sein Passwort autorisiert hat. Ob eine Anforderung diese Autorisierung erwartet kann durch die Methode requiresPreceedingAuthentication der Klasse AccountClientRequest überprüft werden. Ihr könnt Euch dabei nicht darauf verlassen, dass diese Überprüfung immer die gleiche Antwort ergibt!

Um sich mit seinem Passwort beim Server zu autorisieren muss der Client zunächst an den Server ein Objekt der Klasse MyPasswordAuthentication mit seiner Benutzer-ID und seinem Passwort schicken. Der Server überprüft die Korrektheit des Passwortes und schickt an den Client eine entsprechende Anwort. War die Autorisierung erfolgreich kann der Client über diese Socket-Verbindung geschützte Anfragen stellen. Der Server darf keine Anfragen beantworten, wenn die Autorisierung fehlgeschlagen ist.

Als Zusatzaufgabe für nicht ausgelastete. Ihr könnt noch ein "time-out" für eine erfolgreiche Autorisierung einfügen. Wurde über die Verbindung für einen bestimmten Zeitraum keine Anfrage geschickt, so wird entweder die Autorisierung zurückgesetzt und der Client muss sich von neuem mit seinem Passwort identifizieren, oder der Server schließt die Verbindung.

Schlußbemerkung

Überlegt Euch wieder als erstes die genaue Klassenstrukur und die Aufgabenverteilung zwischen den Klassen. Dokumentiert mit Hilfe von javadoc.