Re: Invalid client operations

From: Robert Gregor <gregor ***AT***tugraz.at>
Date: Fri, 3 Nov 2017 10:25:15 +0100
Subject: Re: Invalid client operations
Newsgroups: tu-graz.lv.svu.ue
Organization: Technische Universitaet Graz
Message-id: <othclr$h8e$1@bigmail.tugraz.at>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
References: <otf820$2ec$1@bigmail.tugraz.at>
Hallo Maris,

ich verstehe deine Frage leider nicht so ganz.
Was ist denn z.B. eine Abfrage, die nicht an den Server gesendet werden muss?

Wenn der Client die Dinge schon *wirklich sicher* weiß (und deswegen nichts an den Server senden muss), warum muss es dann überhaupt eine Abfrage geben und wann ist das der Fall?



Noch ein spezieller Hinweis:

(15),(16) dienen im Wesentlichen zwei Dingen:

1. (15) bedingt, dass der Server Requests erkennt, die nicht zu seinem aktuellen Zustand 'passen' oder aber anderweitig 'fehlerhaft' sind. Das ist ein wesentlicher Schritt dafür, dass der Server sich durch solche Nachrichten eben nicht aus dem Konzept bringen lässt. (z.B. Server stürzt ab, weil Name eines neues Channels leer ist... Server stürzt ab, weil ein Channel nicht existiert, dem ein Client beitreten möchte, Server stürzt ab, weil ein Channel angelegt werden soll, der bereits existiert, Server stürzt ab, weil Client bereits subscribed ist, während er erneut versucht eine Subscription zu erlangen ... etc.)

2. (16) Sorgt dafür, dass ein Client mitbekommt, dass eine Aktion nicht funktioniert hat wie gehofft. Das hilft einerseits beim Debuggen, andererseits hilft es dem Nutzer überhaupt zu erkennen, dass eine gewünschte Operation nicht ausgeführt werden konnte obwohl der Request beim Server ankam.



Nochmal in viel expliziterer Form verdeutlicht:

Bitte, bitte *nicht* mehr "Logik" in den Client bauen als von der Aufgabenstellung impliziert wird. In der Praxis macht es in bestimmten Szenarien sicher Sinn, viele Problemfälle bereits auf dem Client zu vermeiden bevor Requests geschickt und Ressourcen auf dem Server beanspruchen werden. Allerdings sorgt das nicht dafür, dass der Server nicht auch mit fehlerhaften Anfragen umgehen können muss. Letzteres ist sehr viel wichtiger als ersteres. Unter anderem deswegen wird in der Aufgabe ganz bewusst auch nur letzteres gefordert.

Hier zwei Denkrichtungen warum es wichtiger ist:

1. Probleme bei Nebenläufigkeit im Verteilten System (oder salopp auch: "Race Condition") : Mehrere Clients versuchen gleichzeitig bestimmte Operation durchzuführen. Dabei erreichen z.B. Server notifications über den neuen Zustand einen der Clients nicht rechtzeitig bevor dieser eine Operation anfordert, die nur nach dem alten Zustand noch zulässig wäre. In unserem Fall bei wenigen Clients und manuellen Tests im lokalen Netzwerk bei stehender Websocket Verbindung und dem asynchronen, single-threaded Abarbeiten von events durch node.js sicherlich verhältnismäßig schwer zu provozieren. Bei steigender Latenz, Client-Anzahl, verbindungslosen Protokollen oder multi-threaded Servern oder aber einem Server, der selbst wiederum ein verteiltes System ist, wird das zunehmend wahrscheinlicher.

2. Ein gelangweilter User des Systems (oder gar ein gewissenhafter Tester im Rahmen des SVU Assignments!) öffnet z.B. die Developer Console im Browser und überschreibt zur Laufzeit ein paar Funktionen im client code um seltsame Nachrichten zu verschicken. Bringt das den Server aus dem Konzept, ist das in der Praxis ein trivial zu findendes Sicherheitsproblem (und in der Übung Punktabzug). Prinzipiell hier auch denkbar: der Server leitet bestimmten Inhalt ungültiger Nachrichten an andere Clients weiter, wo dieser Inhalt dann zu unerwünschtem Verhalten führt. Zur Info: Letzteres wird zumindest innerhalb des vorgegebenen GUI clients für Channel Namen und Nachrichteninhalte schon verhindert, auch wenn die Studenten-Implementierung hier keine checks durchführt.




VG

Robert

On 2017-11-02 14:54, Maris wrote:
Hallo!

Eine Frage bezüglich der 2 Punkten:
(15) The server notifies clients if certain requested operations could not be performed. (16) The client displays a notification if a certain requested operation could not be performed by the server.

Müssen wir wirklich jede einzelne Abfrage auf dem Server ausführen (auch wenn es schönere/leichtere Varianten Client-Side gibt) oder kann es auch von der Implementation abhängen? z.B. um zu prüfen ob der Inhalt einer Nachricht leer ist, macht mir nicht viel Sinn ein WS-Request auf das Server zu schicken und dann das Response zu analysieren, wenn wir schon im Client wissen können, ob es leer ist oder nicht. Wir könnten uns die Ressourcenverschwendung einfach sparen (zwar keine große ^^).

LG,
Maris Siljak