Wo plausibilisieren sich Formular-Daten am besten?

Im Client oder beim Server?

∅ 5 / 2 Bewertungen

Im Client oder beim Server?

Plausibilisierung im Client mit JavaScript

Bei einer Webapplikation kann im Prinzip die gesamte Plausibilisierung bereits im Browser erfolgen, sofern keine Zugriffe auf eine Datenbank notwendig sind. Zwar ist HTML zu keinerlei nennenswerten Plausibilisierungen in der Lage, aber genau dazu wurden ja clientseitige Webtechniken wie JavaScript eingeführt. Mittlerweile ist JavaScript auch die einzige flächendeckend verfügbare, clientseitige Programmiertechnik im Web und es dürfte sogar die mit Abstand wichtigste Anwendung von JavaScript sein; die Möglichkeit Webformulare zu plausibilisieren.

Die Variante, in der sich der Client vollständig um die Plausibilisierung einer Webapplikation kümmert, hat diverse Vorteile. Insbesondere müssen keine fehlerhaften Daten hin und her geschickt werden. Der Clientbrowser kann beispielsweise via JavaScript bereits zahlreiche Abhängigkeiten und Vorgaben prüfen und verhindern, dass ein dahingehend inkorrektes Formular überhaupt zu Server abgeschickt wird. Im einfachsten Fall können Pflichtfelder überprüft werden, aber es kann auch der Inhalt von Feldern bezüglich dem Vorkommen bestimmter Zeichen überprüft werden, der Wertebereich von Zahlen kann überprüft werden, und so weiter.

48131_b4.jpg

Screenshot 4

Ein Nachteil reiner clientseitiger Plausibilisierungen ist jedoch, dass bestimmte Informationen nicht beim Client bereitstehen können. Dies sind alle Informationen, die etwa den Zugang zu einer Datenbank benötigen (beispielsweise ein Prüfung aller gültigen PLZ-Ortsnamen-Beziehungen). Das größte Problem ist jedoch ein anders.

Allgemein kann man zwar heutzutage JavaScript in fast allen Browsern voraussetzen. Allerdings können Anwender die Ausführung von Skripten (oder anderen Clienttechniken) jederzeit in ihrem Browser deaktivieren. Dementsprechend werden Plausibilisierungen, die mit JavaScript im Client stattfinden sollen, bei deaktiviertem JavaScript nicht greifen und Daten in einem Webformular möglicherweise ungeprüft zum Server geschickt werden. Es ist zwar möglich, das ungeprüfte Verschicken der Daten zu erschweren, aber ein geübter Anwender kann diese Schutzmaßnahmen aushebeln.

Plausibilisierung im Server

Wenn der Server via einer Technik wie PHP oder ASP die ausschließliche die Überprüfung von Eingaben in einem Webformular übernimmt, kann man natürlich dort alle Plausibilisierungen durchführen. Das steht außer Frage. Aber auch bei dieser Vorgehensweise gibt es einige gravierende Nachteile. Hier sind drei der Wichtigsten:

  • Das Laufzeitverhalten einer serverseitig plausibilisierten Webapplikation ist schlecht. Bis eine Antwort vom Server auf eine Anfrage zur Plausibilisierung von bestimmten Daten wieder beim Client ist, kann viel Zeit vergehen. Zwar kann man durch neue Techniken wie AJAX nur Teile einer Webseite austauschen und die Menge der auszutauschenden Daten reduzieren, aber dennoch müssen Daten erstmal von Client zum Server und wieder zurück geschickt werden.

  • Es kommt bei einer serverseitig plausibilisierten Webapplikation zu einer starken Belastung der Kommunikationswege durch unnütz hin- und hergeschickte Daten.

  • Es gibt eine starke Belastung des Servers bei gleichzeitigem Brachliegen immenser Client-Ressourcen.

Gerade bei offensichtlich fehlerhaften Daten wie fehlenden Eingaben in Pflichtfeldern in einem Formular wird bei einer serverseitigen Plausibilisierung auf dem Server unnütz Kapazität verbraucht. Ebenso werden die Kommunikationswege mit überflüssigen Daten verstopft und eine Fehlermeldung benötigt unter Umständen immens Zeit, bis sie einen Anwender erreicht. Stellen Sie sich als Beispiel nur einmal ein Formular vor, in dem die Eingabe eines Geldbetrages gefordert wird. Wenn nun ein Anwender dort statt Zahlen Buchstaben einträgt, werden die fehlerhaften Daten - unter Umständen rund um die Welt - zum Server geschickt, der leitet sie zu einem Prüfskript beziehungsweise -programm weiter und erst die serverseitige Applikation bemerkt den Fehler und schickt eine Fehlermeldung als Antwort via dem Server zurück zum Client.

Plausibilisierung in der Datenbank

Nun stellt sich bei Applikationen mit Datenbankanbindung noch die Frage, ob man nicht die Plausibilisierungslogik der Datenbank nutzen kann? Also die Überprüfung der Daten sogar noch hinter den Webserver und dessen zugeordnete Programmiertechnik zu verlagern?

Zwar kümmern sich die Datenbanken quasi von Natur aus selbst darum, dass zumindest die Datentypen und Wertebereiche keine Inkonsistenzen in der Datenbank auslösen. Weitergehende Logik muss aber auch bei Datenbanken manuell programmiert werden. Das ist zwar genauso einfach beziehungsweise schwer zu realisieren, wie es bei der Programmierung von serverseitigen Skripten oder Programmen beziehungsweise clientseitigen Skripten oder Programmen der Fall ist. Aber grundsätzlich spricht zumindest bei Webapplikationen viel dafür, die Plausibilisierung auf Ebene einer Datenbank weitgehend aus dem Spiel lassen. Oder besser gesagt - die Daten sollten bereits vor dem Erreichen der Datenbank so aufbereitet oder abgesichert sein, dass das Plausibilisierungskonzept der Datenbank niemals eingreifen muss.

Denn Erstens gilt bei der Plausibilisierung auf der Datenbank erst recht, dass die Performance sehr schlecht werden kann. Die Prüfung erfolgt ja noch "entfernter" von der Benutzereingabe als in einem serverseitigen Web-Skript. Zweitens belasten Sie neben dem Webserver samt seinen Gehilfen wie dem Skriptinterpreter zusätzlich die Datenbankressourcen. Drittens sind in der Regel die generierten Fehlermeldungen einer Datenbank so aufbereitet, dass sie einem Anwender nicht zuzumuten sind. Sie können zudem nicht von der Datenbank direkt an den Client geschickt werden, sondern müssen vom Webserver an diesen weitergereicht werden.

Dazu ist es in der Regel ein Problem, dass die Datentypen einer Datenbank nicht ohne Konvertierung mit Datentypen aus Webeingaben umgehen können. HTML-Formulare übermitteln ausschließlich Text - auch beispielsweise bei Optionsfeldern. Sie müssen also konvertieren, nur um zu bemerken, dass ein Fehler vorliegt. Im Allgemeinen ist es zwar bei Webdatenbanken wohl am sinnvollsten, die Felder so allgemein wie möglich zu gestalten. Das bedeutet im Extremfall, eine Webdatenbank macht die wenigsten Probleme, wenn sie ausschließlich auf der Basis von Textfeldern arbeitet. Also etwa statt einem Boolean-Feld ein Textfeld ohne irgendeine Plausibilität auf Datenbankseite oder auch bei rein numerischen Eingaben Textfelder zum Speichern. Das steht aber der Effektivität der Datenbank entgegen, weil die Datenbank unter Umständen unnötig groß wird und der Anwender mit einer extrem schlechten Performance gestraft wird.

Sinnvolles Plausibilsierungskonzept: Mehrfache Absicherung

Wie sollten Sie nun aber ein sinnvolles Plausibilisierungskonzept eines Webformulars planen und dann konkret umsetzen? Die Antwort lässt sich aus den bisherigen Bemerkungen schon erahnen:

Eine Plausibilisierung sollte auf allen Ebenen laufen und - sofern möglich - auf allen Ebenen die gleichen Prüfungen durchführen.

Auf jeden Fall ist es sinnvoll, potenzielle Fehler soweit wie irgend möglich bereits beim Client abzufangen. Nutzen Sie auf jeden Fall bereits alle Festlegungen, die Ihnen HTML bietet und die von allen Browsern unterstützt werden. Alles Weitere programmieren Sie mit JavaScript.

Ist eine Plausibilisierung beim Client auf Grund logischer Probleme nicht möglich oder weil der Anwender JavaScript deaktiviert hat, sollten die gleichen Prüfungen auf dem Server wiederholt und durch die ergänzt werden, die nur auf dem Server möglich sind. Da Sie im Allgemeinen aber kaum planen können, ob der Anwender eine clientseitige Plausibilisierung nicht umgehen kann, bedeutet das eine Dublette der clientseitigen Plausibilisierungsschritte auf dem Server. Wenn Sie also auf dem Client mit JavaScript ein Regelwerk programmiert haben, gibt es auf dem Webserver das gleich Regelwerk mit einer dort funktionierenden Technik wie PHP, ASP oder JSP. Die Datenbank sollte danach nur mit verträglichen Werten gefüttert werden. Nur bei nicht einkalkulierten Situationen sollte die Datenbankplausibilisierung einen letzten Firewall darstellen.

Die ideale Basis der Plausibilisierung einer Webapplikation ist also definitiv eine Verteilung der Logik auf Client und Server (samt Redundanz der Überprüfungen). Diese Argumentation spiegelt auch den Hauptgrund für die Einführung von clientseitigen Skriptsprachen wieder - eine Verlagerung von eben solcher Funktionalität vom Server auf den Client, die dort bereits sinnvoll durchgeführt werden kann.

Wann sollte ein Webangebot im Client plausibilisiert werden?

Betrachten wir nun noch einmal die Ebene im Client, wo sie in der Regel mit JavaScripts plausibilisieren werden. Widmen wir uns nun der Überlegung, wann ein Webangebot zu plausibilisieren ist. Die Notwendigkeit der Frage mag im ersten Moment gar nicht klar sein. Aber es ist in der Tat eine der Grundüberlegungen, die bei jeder Applikation durchgespielt werden muss. Zu diesem Zeitpunkt gibt ein Anwender Daten in einem Webformular ein und Sie haben im Grunde jederzeit die Möglichkeit, auf eine Eingabe zu reagieren.

Erinnern Sie sich noch an DOS-Applikationen, die linear von oben nach unten eine Bildschirmmaske abgearbeitet haben? Dann erinnern Sie sich sicher auch daran, dass bei falscher Eingabe der Anwender auf dem betreffenden Feld festgehalten wurde und es solange nicht verlassen konnte, bis das Feld korrekt ausgefüllt war. Das ist jedoch ein Vorgehen, das seit der Einführung grafischer Oberflächen im Allgemeinen nicht mehr tolerierbar ist.

Es ist im Web vollkommen inakzeptabel, einen Anwender in einem Eingabefeld eines Webformulars festhalten zu wollen, nur um eine bestimmte Art der Eingabe zu erzwingen. Das führt nicht nur zu Ärger und Akzeptanzverlust beim Anwender - es widerspricht der Art der grafischen Benutzerführung. Eine Eingabemaske wird von vielen Anwendern kreuz und quer ausgefüllt. Und wenn in einem Feld etwas Falsches steht, hat der Anwender vielleicht keine Lust, es unmittelbar zu korrigieren, sondern er möchte möglicherweise zuerst ein anderes Feld ausfüllen. Das muss ihm gestattet werden.

Technisch gesehen bedeutet das, dass eine Überprüfung bei der unmittelbaren Eingabe oder beim Verlassen eines Feldes fast gar nicht mehr Usus ist. Auf keinen Fall jedoch bei Webapplikationen, obwohl gerade da solche Aktionen leicht zu realisieren sind. Eventhandler wie onBlur oder onFocus sind ja gerade dazu bestimmt, beim Verlassen eines Formularfeldes beziehungsweise bei dessen Fokussierung bestimmte Aktionen auszuführen.

Das können dann auch Schlüssigkeitsprüfungen sein, aber diese dürfen keine Plausibilitäten auslösen, welche die Art des Ausfüllens von einem Webformulars so beeinflussen, dass der Anwender in seiner Freiheit eingeschränkt ist. So ist das Löschen einer offensichtlichen Fehleingabe beim Verlassen eines Feldes vielleicht noch tolerierbar. Ebenso, wenn Sie nach einem Eingabefehler und dem Löschen der Eingabe den Fokus wieder auf dieses fehlerhafte ausgefüllte und nun leere Feld setzen. Aber der Anwender muss dann das Feld verlassen dürfen, ohne dass er zu einer Eingabe gezwungen wird.

Unangenehm für einen Anwender wird es auch, wenn er ein Feld verlässt und bei einem Fehler ein alert()-Fenster oder einen ähnlichen Dialog vor die Nase geknallt bekommt, der explizit bestätigt werden muss. Wenn das bei mehreren Feldern in einem Formular vorkommt, wird der Anwender sicher ziemlich verärgert reagieren. Die Möglichkeiten von DHTML erlauben es zu dem, Fehlermeldung und Hinweise so in einer Webseite anzuzeigen, dass Sie einen Anwender zwar informieren, ihn aber nicht in der Bedienung eines Webformulars behindern.

48132_b6.jpg

Screenshot 5

Allgemein hat es sich aber bei Webapplikationen dennoch als sinnvoll erwiesen, weder beim Fokussieren noch beim Verlassen von Formularfeldern zu plausibilisieren. Aber wo denn dann? Am sinnvollsten ist es in den meisten Fällen, wenn man erst beim Abschicken eines Formulars zum Server (zum Beispiel im Rahmen des Eventhandlers onSubmit oder vor dem Aufruf der Formularmethode submit() beziehungsweise beim Aufbau einer neuen Seite die Eingaben des Anwenders überprüft.