siehe auch:
(1): Was ist Ajax?
(2): Warum heißt Ajax so? Wo kann ich Ajax in Aktion sehen?
(3): Worin besteht die Ajax-Schnittstelle? Wie wird Ajax standardisiert?
Welche Nachteile hat Ajax?
Bei allem Mehrwert, den Ajax dem Benutzer einer Webanwendung bieten kann, sollen jedoch die Nachteile nicht verschwiegen werden. Folgende Probleme treten im Zusammenhang mit Ajax auf:
- Die Grenzen zwischen URL-Adressen und Seitenzuständen verschwimmen:
Eine Webseite zeichnet sich dadurch aus, dass sie eine feste URL-Adresse hat. Wenn eine Webseite intensiv mit Ajax arbeitet, kann es jedoch passieren, dass der Benutzer lange Zeit gar keine neue Seite mit eigener URL-Adresse nachfordert. Stattdessen setzt ihm JavaScript neue Inhalte und Seitenzustände direkt in den bestehenden HTML-Code ein. Da so erzeugte Inhalte und Seitenzustände aber keine eigene URL-Adresse haben, lassen sie sich nicht als Bookmark/Favorit abspreichern, und andere Webseiten können keine direkten Links („Deeplinks“) auf solche Inhalte setzen. Die Vor- und Zurück-Funktion des Browsers, die das Bewegen in der Historie besuchter Seiten ermöglicht, funktioniert ebenfalls nicht mehr wie erwartet. Denn diese Funktion springt immer nur zum Anfangszustand einer Seite. Auch Suchmaschinen-Robots werden in aller Regel nur den Anfangszustand einer Seite indexieren und weitere, über Ajax ermittelbare Seiteninhalte ignorieren.
- Ajax ist nur mit aktiviertem JavaScript verfügbar:
Per Voreinstellung ist JavaScript in allen modernen Browsern aktiviert. Weil JavaScript jedoch nach dem Boom der Anfangsjahre etwas in Verruf geraten war, nutzten viele Anwender die Möglichkeit, JavaScript zu deaktivieren. Viele nervige Popup-Fenster, hinderliche Effekten und sonstiges Blendwerk ließen sich auf diese Weise unterdrücken. Wer das auch heute noch tut, wird von Inhalten, die nur über Ajax ermittelt werden, erst gar nichts sehen. Gleiches gilt für Anwender, die aus technischen oder körperlichen Gründen Browser-Lösungen in reinen Textumgebungen verwenden. Solche Browser unterstützen in aller Regel auch kein JavaScript. Inhalte, die nur über Ajax ermittelbar sind, bleiben also unzugänglich.
- Die Server-Belastung kann sehr hoch werden:
Wenn Anwenderaktionen wie Mausklicks oder gar Mouseover-Ereignisse jedesmal eine HTTP-Kommunikation auslösen, entsteht viel zusätzliche HTTP-Kommunikation zwischen Client und Server. Der Client, also der Browser des Anwenders, wird dadurch nicht nennenswert belastet, um so mehr jedoch der Webserver, der möglicherweise für viele gleichzeitige Benutzer die Ajax-bedingte HTTP-Kommunikation abwickeln muss. Eine Ajax-intensive Webanwendung, die von vielen Besuchern gleichzeitig genutzt wird, kann einen Webserver durchaus in die Knie zwingen. Das gilt insbesondere für Anwendungen, bei denen eigentlich ein Server-Push, also eine vom Server gestartete Kommunikation sinnvoll wäre, wie etwa bei einem Chat. Da es im HTTP-Protokoll jedoch keinen Server-Push gibt, muss der Client, also JavaScript, in kurzen Zeitintervallen immer wieder beim Server nachfragen.
- Wartezeit bis HTTP-Antwort kann Anwendungen lahm erscheinen lassen:
Wenn ein Anwender in seinem Browser eine neue Webseite aufruft, weiß er, dass es einen oder ein paar Momente dauern kann, bis alle Daten angezeigt werden können. Eine Webanwendung, die mit Ajax Daten „nachlädt“, muss ebenfalls einen oder ein paar Momente auf Antwort warten. Ein Anwender, der nichts von Ajax weiß (und welcher Normalanwender muss das schon wissen?), bekommt in solchen Fällen den Eindruck, als ob die Webanwendung sehr zäh reagiert. Er klickt auf einen Button und muss möglicherweise mehrere Sekunden warten, bis das Ergebnis des ausgelösten Ereignisses sichtbar wird. Dies widerspricht seiner Erfahrung, wonach einmal geladene Webseiten sich im Speicher des eigenen Browsers befinden und sehr schnell reagieren.
Einige dieser Probleme sind allerdings durchaus lösbar. Eine Webanwendung kann beispielsweise so konzipiert werden, um GET-Parameter zu erkennen, über die sich direkt Inhalte und Seitenzustände ansprechen lassen, die sonst erst durch Ajax-Aktionen zustande kommen. Bei Wartezeiten, verursacht durch Ajax-HTTP-Anforderungen im Hintergrund, kann dem Anwender ein bekanntes Warte-Symbol (z.B. eine Sanduhr) angezeigt werden.
Was die Verfügbarkeit von JavaScript betrifft, so müssen Webentwickler eine Grundsatzentscheidung treffen. Entweder man macht die Aktivierung von JavaScript einfach zur Bedingung, oder man versucht, Ajax nur für Mehrwert-Funktionen eingesetzt werden (z.B. Tabellensortierung), wobei eine Grundfunktionionalität (z.B. Tabelle, die nicht sortierbar ist) gewährleistet ist. Vor allem Websites, die den Charakter einer Webanwendung haben, mit der Benutzer etwas bearbeiten können, haben durchaus das Recht, die Aktivierung von JavaScript zur Bedingung zu machen. Bei gewöhnlichen Webseiten ist dagegen eher die Lösung angebracht, Ajax nur für Mehrwert-Funktionalität einzusetzen.
Wie sicher ist Ajax?
JavaScripts mit Ajax stoßen Scripts an, die auf einem Webserver laufen, also beispielsweise PHP-Scripts. Das serverseitige Script muss sich dazu in der „Document Root“ des Webservers befinden, also in jenem Verzeichnisbereich, der über URLs adressierbar ist. Das klingt gefährlich. Doch letztlich passiert dabei nichts anderes, als wenn ein Anwender die URL-Adresse eines solchen Scripts auf dem Webserver selbst in die Adresszeile seines Browsers eingibt, oder wenn er sich selbst ein HTML-Formular bastelt, das ein solches Script beim Absenden aufruft und ihm Daten übermittelt. Es liegt in all diesen Fällen an der serverseitigen Programmierung, dafür zu sorgen, dass über GET-Parameter oder POST-Daten keine ungewollten oder schädlichen Aktionen auf dem Server ausgelöst werden.
Das Sicherheitskonzept von Ajax geht jedoch noch einen Schritt weiter. Es sieht vor, dass ein JavaScript, welches das XML-HTTP-Objekt einsetzt, vom gleichen Webserver kommen muss wie das serverseitige Script, das es aufruft. Es ist also nicht möglich, durch ein selbstgebasteltes JavaScript via Ajax ein serverseitiges Script auf einem beliebigen Webserver zu starten.
Fehlermeldung in der JavaScript-Konsole des Firefox-Browsers beim Versuch eines JavaScripts, einen HTTP-Request an eine fremde Domain zu senden
Im Klartext bedeutet das: Ein Benutzer muss in seinem Browser zunächst eine Webseite auf einem Webserver aufrufen. Diese Webseite enthält ein JavaScript mit Ajax-Code. Das Script wird zusammen mit der Webseite an den Browser des Anwenders übertragen. Das Script mit dem Ajax-Code kann nun HTTP-Requests absenden, jedoch nur zu dem Webserver (genauer: zu der Domain), von welcher die Webseite mitsamt dem Script an den Browser übertragen wurde.
Als Website-Betreiber müssen Sie entweder ein eigenes JavaScript mit ausliefern, das serverseitige Scripts auf der eigenen Domain aufrufen kann. Oder Sie binden ein JavaScript von einer fremden Domain ein, das jedoch nur serverseitige Scripts auf der Domain aufrufen kann, von der es ausgeliefert wird.
Wie sicher eine Ajax-basierte Web-Umgebung ist, bleibt also daran hängen, wie sicher die serverseitige Programmierung ist, welche Ajax-Anfragen verarbeitet. Ein PHP-Script etwa, das ungeprüft Daten, die aus GET- oder POST-Parametern stammen, in ein MySQL-Statement einbaut und die Daten in eine Datenbank schreibt, stellt ein hohes Sicherheitsrisiko dar. Dieses Risiko kann jedoch ebensowenig der Ajax-Schnittstelle angelastet werden wie der Programmiersprache PHP. Es liegt allein an der Sorgfalt der serverseitigen Programmierung, mit Input-Daten so umzugehen, dass daraus keine Gefahr entstehen kann.
