Was sind die Vorteile und Nachteile von clientseitiger Webprogrammierung?

4 Antworten

Ich glaube, das könnten wir noch etwas ausformulieren:

Bei Webanwendungen geht es in der Regel darum dass verschiedene Parteien mit einander durchaus entgegengesetzten Interessen in eine Kommunikation eintreten.

In einem Shop zum Beispiel möchte der Betreiber, dass seine angebotenen Waren von den Kunden für möglichst viel Geld gekauft werden, während die Kunden möglichst viel Ware für möglichst wenig Geld bekommen wollen - am besten sogar für gar nichts. In Foren zum Beispiel gibt's gleich eine ganze Armada von Interessengegnern, darunter so dominante wie das Rechtssystem mit dessen Aufpassern, Werbetreibende, Datenmissbraucher, blatante Gauner und Gangster und daneben immer auch noch ein paar Nutzer, die noch alle Tassen im Schrank haben.

Du wirst als Serverbetreiber - egal, ob es um Shops geht oder um völlig kostenlose Portale für Fans irgendeines Hobbys - nie darum herum kommen, Dich gegen Leute zur Wehr zu setzen, die Dich ausnehmen wollen oder schlicht Deine Dienste für Dinge missbrauchen, von denen Du nicht mal träumen möchtest.

In dieser Umgebung ist es zwingend notwendig, einige Vorgänge in einer Webanwendung den Krallen der Nutzer vorzuenthalten. Namentlich alles, was Dir Schaden zufügen kann oder wofür Du von Dritten und Vierten Leuten zur Verantwortung und über den Tisch gezogen werden kannst.

Diese Dinge sind Dinge, die man nicht auf der Seite des Clients entscheiden und erledigen lassen kann - denn dort sind diese Dinge dem Einfluss der Ar... der unartigen Menschen dieser Welt ausgeliefert.

======================

Ein bisschen weiter gedacht - um eine Ecke - ergibt sich noch folgendes: Es gibt keinen einzigen Serverbetreiber auf dieser Welt, der so gut ist, dass er restlos sämtliche Programmschnipsel, die er je geschrieben hat und auf seinem Server laufen lässt (nur auf dem, das heißt: die Client-seitigen Programmschnipsel lassen wir hier aus der Betrachtung noch völlig aus, die kämen bei vollständiger Betrachtung noch oben drauf!), auch nur soweit fehlerfrei halten könnte, dass er gegen jeden Hacking-Versuch bestehen würde. Selbst und in den letzten Jahren GERADE sogenannte Sicherheitsfirmen werden immer wieder zum Opfer von Hacks. GERADE eben solche Firmen, die damit auftrumpfen, für die Sicherheit vom Rest der Welt sorgen können zu wollen.

Wenn aber ein Server von einem Hacker übernommen wurde, wird damit der Serverbetreiber - ob er es will oder nicht - zum Malwareverbreiter und Mithelfer des eigentlichen Täters. Weil er faktisch dem Gauner die Serverressourcen zur Verfügung stellt und seine gesammelte Kundschaft direkt in den Rachen des Gauners wandern lässt. Zumindest werden die Kunden es zunächst mal so empfinden.

In einer solchen Situation sind Kunden, die sich daran gewöhnt haben, jedwedem Server draußen im WWW jedwedes Javascript-Programm zu erlauben, nahezu hoffnungslos den Gaunern ausgeliefert. Da hilft auch kein Antiviren-Programm. Ganz besonders nicht, falls der Antiviren-Hersteller derjenige ist, der gehackt wurde. Was wir auch schon hatten.

Hat man dagegen als anständiger Webanwendungsprogrammierer seine Webanwendung so angelegt, dass die Kunden keinerlei clientseitige Programmausführung benötigen, um die Webanwendung benutzen zu können, können die Kunden mit abgeschaltetem Javascript (also abgeschalteter clientseitiger Programmausführung) daherkommen und sind damit per se gegen nahezu alle Malware-Verbreitung geschützt, weil fast jede Malware-Verbreitung als ersten Schritt voraussetzt, dass auf dem Client-Rechner in dessen Browser automatisch Angriffsaktionen ausgeführt werden können, was per se unmöglich ist ohne clientseitige Programmausführung.

Die Frage, ob server- oder clientseitige Programmierung hat also einen krass zuschlagenden Sicherheits-Aspekt: Jeder Anwender, der freiwillig bei sich clientseitige Programmausführung zulässt, liefert sich global und aus eigenem Willen der weltweiten Web-Mafia aus. Jeder, der dies unterbindet, ist nahezu perfekt vor dieser Mafia geschützt. Per se. Ohne an irgendwelchem Antiviren-Schlangenöl auch nur gerochen zu haben.

P.S.: Was gilt jetzt eigentlich als "vulgär, beleidigend oder aus rechtlichen Gründen nicht zulässig"? Wenigstens eine Andeutung von Seiten der Forensoftware wäre nett. Ist etwa "Schlangenöl" hierzulande neuerdings "vulgär"??? Krass.

Vorteil: Es funktioniert standardmäßig auf keinem meiner Rechner, und erspart mir somit nerviges Geblinke und "schicken Web 2.0" Müll.

Nachteil: Einige Seiten sind so grottenschlecht programmiert, dass sie kein Serverseitiges-Fallback haben, und die Entwickler der Seite auch nicht in der Lage sind, einen Text für Leute ohne aktives JS anzuzeigen. Solche Seiten kann man dann aber einfach meiden, also kein großes Problem.

Viele Webseiten-Betreiber setzen JS auch für Sicherheitskritische Anwendungsfälle ein ... ähem, GF ... und denken dann, dass man JS-Code, welcher durch einen Obfuscator gejagt wurde, nicht mehr lesen kann. :)

key = md5(user + message + salt); // sinngemäß

Naja, aber so einen Pfusch gibt es glücklicherweise nicht überall. :)

Vorteil: Schneller weil Anfragen nicht erst zum Server geschickt und dort bearbeitet werden müssen. 

Nachteil: Der ganze Quellcode ist für jeden ersichtlich und somit nicht vor diebischem Gesindel geschützt. :)

---

Wie beim Kochen macht es die Mischung!

RakonDark  22.09.2015, 16:10

öhm , gehts hier um marketing ? das ja schon lange nicht mehr das problem lol , auch JS kann man durchcrypten , viel wichtiger wie in der anderen antwort , es ist manipulierbarer und muss dann vom server wieder überprüft werden .

0

Vorteil: Weniger Serverauslastung, Nachteil: manipulierbar.