nicht angemeldet
ich hielte es für sinnvoll, dass du über die Sicherheitsimplikationen dieser Zeile berichtest.
Also, wenn das sendende Skript, das auf dem selben Server liegt wie die Ressource in der das Javascript verwendet wird, dann hat derjenige, dessen Server hier Mist sendet, ganz gewiss kein Problem mit dem Javascript, sondern damit, dass ein böswilliger Dritter dort überhaupt Dateien oder Daten (Hier: In der Datenbank) verändern kann.
Mithin: Kann der das sendende PHP-Skript ändern, so kann er sehr wahrscheinlich auch die Datei ändern, die den xmlHttp-Request auslöst. Ergo auch das Javascript selbst.
Du kannst ja mal versuchen, einen Angriff zu beschreiben, bei dem er das nicht müsste. Bedenke dabei, dass der Inhalt der Datentabelle nicht "User-Generated-Content" ist.
Dann müsste ohnehin etwas gemacht werden, das sollte aber auf der Serverseite geschehen und zwar bevor er JSON-String gebaut wird.
Zu Deiner anderen Ausführung: Wenn ich jQuery gar nicht erst benutze - also gar nicht erst lade - warum sollte ich dann berücksichtigen, dass jQery dieses oder jenes mit den Daten aus xmlHttp.responceHeaders (kennt der aktuelle Firefox nicht mal) versucht?
Wenn ich einen Baumstamm den Bach runter haben möchte, dann schmeiße ich den da rein. Ich komme nicht mal auf die Idee, den Bach 15m tief und 90m breit auszubaggern, einen Hafen zu bauen und dann einen Hochseedampfer mit dem einen Baumstamm zu beladen, der auch 40m hohen Wellen standhalten kann. Falls es die jemals in dem Bach gibt, dann ist nämlich auch die Sägemühle weg. Mitsamts dem Dorf.
Apopros Dorf:
Darin wollen wir - bitte - die Kirche lassen. Genau deshalb lehne ich die Verwendung von jQuery ab, wenn es, wie vorliegend, nur darum geht, ein wenig im Dokument "herumzupoken".
Apopros Wiederverwendbarkeit des Codes:
Mehr als 99% aller Websites beinhalten nur wenige Funktionen, die sich wie vorliegend mit nativen Java-Skript leicht und performant erledigen lassen. Aus der Frage kann ich sehr bestimmt vermuten, dass diese Seite dazu gehören wird. Diese Webseiten haben (im wesentlichen) oft auch 5 bis 10 Jahre Bestand. Wieso sollte, wenn es sehr viel einfacher und sehr viel billiger geht, denn ein Wahnsinns-Aufwand getrieben werden, etliche - nicht selbst beherrschbare Fehlerquellen (Bugs in den Bibliotheken) - "nachgerüstet" werden, um irgendwelchen schönen Theorien zu genügen, z.B. den Code "wiederverwendbar" zu machen - wenn bis dahin womöglich der Stand der Technik ein ganz anderer ist?
Schreibst Du Deine Skripte denn mit einer Textverabeitung, weil Du die dann so schön als PDF exportieren kannst - die nachträglich gezippt schließlich auch nur wenig Platz auf der Platte brauchen?
Der Martin
Matthias Apsel