Aktuelles
Termine
Themen
FAQs
Rückblick
Regionales
Kontakt
Sitemap
Impressum
Aktive Inhalte im Web - ein ÜberblickAm Mittwoch, den 24.04.2002 ging es beim turnusmäßigen Termin des HITFORUMS Rhein/Ruhr in Herten um "Aktive Inhalte im Web". Diese Seite fasst die Themen des Abends zusammen und wird ständig inhaltlich erweitert - Aktuelle Version 1.15. Hinweise, Fragen, Korrekturen, Beispiel, Beiträge, Tipps und Links sind immer herzlich willkommen! Bitte hier melden! ÜberblickClientseitige Dynamik
Clientseitige TechnikenEin erste grobe Unterteilung kann danach vorgenommen werden, auf welcher Seite im Client-Server-Modell die Dynamik angesiedelt ist. Auf der Seite des Clients kommen Skriptsprachen wie JavaScript oder Browsererweiterungen, wie Plugins, Java Virtual Machines und ActiveX zum Einsatz. Im folgenden betrachten wir diese Techniken näher, später werfen wir dann einen Blick auf die serverseitigen Techniken. JavaScriptJavaScript ist eine Erweiterung des Browsers und wird direkt vom Browser interpretiert und ausgeführt. JavaScript 1.0 wurde von Netscape mit dem Navigator 2.0 in die Welt gesetzt und seitdem ständig weiterentwickelt, es folgten die Versionen 1.1, 1.2, 1.3 und jetzt neu 1.5. JavaScript erlaubt solche Dinge wie Laufschriften, Texte als Programmausgabe, Farbänderungen, Menüs, Dialogboxen, Reaktionen auf Mausbewegungen, das Öffnen und Schliessen von Browserfenstern (Popup), aber auch die lokale Überprüfung von Formulareingaben bevor diese an den Server geschickt werden. Dadurch dass es mittlerweile die verschiedensten Versionen von JavaScript gibt und zusätzlich noch JScript von Microsoft, ist es für den Webdesigner nicht ganz einfach, alle Browser korrekt zu unterstützen. So muss häufig der Typ (Netscape, Opera, Internet Explorer) und die Version des Browsers ermittelt werden, um dann mit jeweils spezifischen Codezeilen zu agieren. Genau genommen hat JavaScript eigentlich nichts mit der Sprache Java zu tun, es nutzt lediglich eine Java-ähnliche Syntax. Tatsächlich wollte Netscape JavaScript ursprünglich Livescript nennen. Erst in letzter Minute wurde in Abstimmung mit Sun der marketingmäßig vorteilhaftere Name JavaScript gewählt. Übrigens ist JavaScript von Netscape nicht allein für den Client-seitigen Einsatz erdacht worden. Bei Webservern von Netscape kann JavaScript auch serverseitig als Skriptsprache eingesetzt werden (http://developer.netscape.com/docs/manuals/js/server/jsguide/jsserv.htm). Etwas weiter unten findet sich ein kleines JavaScript-Beispiel mit Quellcode und Erläuterungen. Weitere Informationen zu JavaScript gibt es hier: SELFHTML Link-Verzeichnis JavaScript und DOM: JavaScript-Workshop bei Lycos: JavaScript Guidelines and Best Practice: Ein historischer Überblick zur Entwicklung von JavaScript: All about JavaScript: JavaScript Documentation JavaScript Newsgroup FAQ: Nähere Infos zu JavaScript JScript, VBscriptBei JScript und VBscript handelt es sich um Microsoft-spezifische Skriptsprachen, die demzufolge auch nur vom Internet Explorer unterstützt werden. JScript ist die MS-Variante von JavaScript und seit der ersten Version des Internet Explorers (das war die Version 3.0) auf dem Markt. Gleichzeitig hat Microsoft auch noch VBscript herausgebracht, das auf Visual Basic basiert. Link: http://msdn.microsoft.com/scripting/jscript/ ECMA-ScriptBei ECMA-Script handelt es sich nicht tatsächlich um eine weitere Scriptsprache, sondern vielmehr um den Versuch per Standardisierung einen verbindlichen Funktionsumfang für Scriptsprachen festzulegen. ECMA-Script orientiert sich an JavaScript, ist aber damit nicht identisch. Sowohl Netscape als auch Microsoft haben ihre Sprachen im Lauf der Zeit dem ECMA-Standard angepasst, bringen aber immer noch darüber hinausgehende Erweiterungen. Näheres zu ECMA-Script findet sich unter www.ecma.ch. Document Object Model (DOM)Die Standardisierung durch die ECMA regelt zwar den Sprachumfang der Skriptsprache , hiermit ist aber noch nicht festgelegt, wie Browser und Skriptsprache interagieren können, wie also per Skript auf die Elemente des darzustellenden Dokuments zugegriffen werden kann. Viele der anfänglichen Probleme mit JavaScript resultieren daher, dass hier jeder Browser seinem eigenen Modell folgte. Mit dem Document Object Model (DOM) des w3.org gibt es mittlerweile aber einen Standard, der von den neuesten Browsern auch unterstützt wird. Näheres zu DOM findet sich unter www.w3.org/TR/REC-DOM-Level-1. Beispiel JavaScriptEin Beispiel für den Einsatz von JavaScript findet sich hier. Der Sourcecode des Beispiels:
<script language="JavaScript">
<!--
do { var a = prompt("Bitte die erste Zahl eingeben!","");
var b = prompt("Bitte die zweite Zahl eingeben!","");
var c = a*1+b*1;
document.write("<p>",a," + ",b," = ",c,"</p>");
}
while (c!=0);
-->
</script>
<noscript>
<p><b>Sorry, Ihr Browser unterstützt kein JavaScript.
Daher läuft das Beispiel leider nicht!</p>
</noscript>
Erläuterung Das eigentliche Skript steht zwischen den Tags <script> und </script>. Generell ignorieren Browser alle Tags, die sie nicht kennen und versuchen den zwischen den Tags stehenden Text anzuzeigen. Um nun zu verhindern, dass ältere Browser den Skriptcode anzeigen, statt ihn auszuführen, ist der JavaScript-Code als HTML-Kommentar gekennzeichnet, also zwischen <!-- und --> gesetzt worden. Neuere Browser brauchen diese Hilfe nicht mehr, daher wird es zunehmend unüblicher sie einzusetzen. Unter XHTML 1.0 führt das Einkommentieren sogar zu einem Problem, da unter XML alle Kommentare vom Browser vorab verworfen werden - unabhängig davon, wo sie stehen. Das Einkommentieren führt bei XHTML 1.0 also zu einem leeren Skript-Tag. Ein Ausweg um sowohl XHTML- als auch Altbrowser-kompatibel zu bleiben ist nur das Auslagern des Skript-Codes in eine eigene Datei. Zwischen den Tags <noscript> und </noscript> steht der Text, der von Browsern angezeigt werden soll, die entweder kein JavaScript kennen oder bei denen es abgeschaltet worden ist. Egal ob der Browser die Tags nun kennt oder nicht, er wird den Inhalt zwischen den Tags anzeigen. Lediglich bei aktiviertem JavaScript wird nun wiederum alles zwischen den Tags übergangen. Übrigens, mal ehrlich, wem ist die seltsame Zeile var c = a*1+b*1; aufgefallen??? Nun, wenn man stattdessen einfach var c = a+b; schreiben würde, dann würden die beiden Zahlen nicht addiert, sondern die beiden eingegebenen Strings einfach zusammengesetzt. JavaScript kennt nämlich keine expliziten Datentypen, alles sind erstmal Strings. Das ist einerseits genial einfach, bei speziellen Gelegenheiten wie hier aber auch extrem lästig. Der Operator "+" auf Strings angewendet bedeutet nämlich, dass sie miteinander verkettet werden ("concatenation"). Erst wenn wir durch irgendwelche Maßnahmen klarstellen, dass hier Zahlen gemeint sind, wird das "+" als Addition erkannt. In unserem Beispiel zu HTML-Formularen gibt es dasselbe Problem und eine ähnlich sinnige Lösung :-) . PluginsClientseitig kommen häufig auch noch sogenannten Plugins zum Einsatz. Das sind installierbare Erweiterungen des Browsers, die spezielle Dateiformate unterstützen und so beipielweise Multimedia-Anmimation oder ähnliches ausführen. Bekanntester Vertreter dieser Kategorie dürfte der "Flash"-Plugin sein. <FLAME>Dieser ist bei manchen Designer so beliebt, dass sie am liebsten gar niemanden mehr auf ihre Seiten lassen wollen, der nicht über die jeweils neueste Version verfügt. Manche sind immerhin so generös, dass sie es gestatten, ihre Kunstwerke zu ignorieren ("Skip Intro"). Andere sind da weniger einfühlsam. Da heisst es entweder Plugin installieren oder draussen bleiben.</FLAME> Macromedia Flash: http://www.macromedia.com/software/flash/ Java-AppletsBei Java-Applets handelt es sich um "richtige" Java-Programme, die speziell so erstellt worden sind, dass sie vom Browser in seiner eigenen Java Virtual Machine (VM) ausgeführt werden können. Hiermit sind auf dem Client weitestgehend alle Dinge möglich, die eine vollwertige Programmiersprache eben bietet. Der Browser lädt das Applet vom Server, was je nach Größe des Applets durchaus einige Zeit in Anspruch nehmen kann ("applet loading"). Bei späteren Aufrufen ist eine erneuter Download nicht mehr notwendig. Java-Applets laufen in einer gekapselter Umgebung ("Sandbox"), was ihre Möglichkeiten aus Sicherheitsgründen stark einschränkt. Wenn der Anwender es aber möchte, kann er diese Einschränkungen aufheben, um dem Applet auch weitergehende Möglichkeiten einzuräumen (Zugriff auf das Dateisystem, etc.). Grundsätzlich ist die Ausführung eines fremden Programms auf dem eigenen Rechner immer ein potentielles Sicherheitsrisko, da die geplanten Schutzmaßnahmen immer wieder Lücken aufweisen. Applets werden unter anderem gerne beim Homebanking eingesetzt. Hier stellt die Bank das entsprechende Applet zum Downlaod zur Verfügung, das dann clientseitig z.B. auf einen Kartenleser und die eingelegte Chipkarte zugreifen kann (HBCI). Java wird ständig weiter entwickelt. Entsprechend gibt es auch verschiedene Versionsstände. Nicht jeder Browser hat aber unbedingt schon die passende VM. Hieraus können Probleme resultieren. Ansonsten sind Applets, genau wie Java selber, schon eine geniale Idee. Ein Java-Applet kann normalerweise genauso gut auf einem Windows-PC, auf einem Mac oder unter Unix ausgeführt werden. Es ist unabhängig vom darunterliegenden Betriebssystem. Nähere Infos zu Java ActiveXDeshalb gibt es bei Microsoft "ActiveX". Hier wird ebenfalls Code vom Server zum Client heruntergeladen. Allerdings werden hierbei nur Clients mit einem Windows-Betriebssystem unterstützt. Unix, Macs und dergleichen müssen leider draussen bleiben. Dadurch dass ActiveX sozusagen immer ein Heimspiel hat, also auf einem Windows-System ausgeführt wird, kann es mit speziellen Funktionen glänzen, die bei Applets nicht so einfach und elegant möglich sind. Diesen Vorteil erkauft man sich aber mit einer verschärften Sicherheitslage! ActiveX läuft nicht in einer "Sandbox"! Das ActiveX-Programm läuft mit allen Rechten des angemeldeten Benutzers ohne jede Einschränkung! Das Sicherheitsmodell von Microsoft setzt stattdessen auf zertifikatsbasiertes Vertrauen. Das ActiveX-Programm präsentiert ein Zertifikat und der Anwender muss (im Einzelfall oder grundsätzlich) entscheiden, ob er der Software vertraut. Diese Zertifikate beziehen sich nicht, wie man vielleicht irrtümlich annehmen könnte, auf das jeweils vorliegende Softwareprodukt. Die Software selber ist von niemandem ausser (hoffentlich zumindest) vom Hersteller auf Sicherheitslücken oder gar Schadroutinen untersucht worden. Das Zertifikat besagt lediglich, dass der Hersteller dieser Software die Firma XYZ ist und das Programm nicht zwischenzeitlich von anderen verändert worden ist. Genau genommen sagt das Zertifikat sogar nur aus, dass der Aussteller des Zertifikats von der Identität des Softwareherstellers überzeugt ist, mehr nicht. Wie er zu dieser Überzeugung gekommen ist, ist unklar, da müssen wir ihm schon vertrauen. Peinlicherweise ist es der Firma Verisign (einem der wirklich namhaften Zertifikatsanbieter) passiert, dass sie jemandem fälschlicherweise Zertifikate ausgestellt hat, die ihn als "Microsoft" ausgewiesen haben. Da dummerweise in dem ganzen Überprüfungsmechanismus von Microsoft keine online Gültigkeitsprüfung der Zertifikate vorgesehen ist (d.h. es gibt keine "CRL" Certificate Revocation List, Liste der zurückgezogenen Zertifikate) musste Microsoft eine ganze Reihe von Patches für die verschiedensten Windows-Betriebssysteme herausbringen, die nun (sofern installiert) dafür sorgen, dass genau diese Zertifikate herausgefiltert werden! Durch das Zertifikat wissen wir also, von wem die Software (wahrscheinlich) stammt. Dann müssen wir uns entscheiden, ob wir Software aus dieser Quelle vertrauen. Läuft das ActiveX-Programm erst einmal, dann ist sein Funktionsumfang in keiner Weise eingeschränkt oder wenigstens kontrollierbar. Auch auf die Gefahr hin, zu langweilen: Das Zertifikat sagt nichts über die Software selber aus. Nähere Infos zu ActiveX Zusammenfassung clientseitige DynamikAllen bisher erwähnten Techniken ist gemeinsam, dass sie clientseitig, also auf dem Rechner des Websurfers in dessen Browser oder in einer Erweiterung davon ausgeführt werden. Hierzu wird der aktive Code zusammen mit der HTML-Seite vom Server an den Client übertragen und dort vom Webbrowser, der Java-Umgebung (VM) oder einem Plugin interpretiert. Da die Ausführung clientseitig erfolgt, treten hier gegebenenfalls auch alle Sicherheitsprobleme auf. Serverseitig werden keinerlei Ressourcen benötigt, Diese Art von Dynamik kann auch mit einer minimalen Webpräsenz ("Webvisitenkarte") genutzt werden. Serverseitige DynamikClientseitige Skripte bieten ganz nette Möglichkeiten, um Webseiten aufzupeppen. Wirklich ernsthafte Anwendungen benötigen aber serverseitige Unterstützung. Wer eifrig durch das Web surft und dabei ab und zu einen Blick auf die URL-Anzeige des eigenen Browsers wirft, wird dort eine Vielzahl von Dateiendungen entdecken. Hier gibt es nicht nur die gewohnten html- oder htm-Dateien, sondern beispielsweise auch die folgende Extensions: asp, jsp, php, phtml, shtml, pl, cfm, ... Manche URLs haben auch "kryptische" Anhänge der folgenden Art: http://www.hitforum.de/demo.php?num1=333&num2=555 Dies sind typische Kennzeichen für die Nutzung dynamisierter Webseiten. Bei serverseitiger Dynamik werden die Anfragen (HTTP-Requests) des Browser nicht einfach dadurch beantwortet, dass eine auf dem Web-Server vorhandene HTML-Datei unverändert zurückgeliefert wird. Vielmehr wird die Ausgabe stets neu erzeugt und beispielsweise aus statischen und dynamischen Anteilen zusammengesetzt. So ist es möglich, dass vom Benutzer ausgefüllte Formulare auf dem Server ausgewertet werden können. Keine Suchmaschine könnte ohne diese Funktionalität ihre Dienste anbieten. Oder aber Besucher einer Website können sich per Login anmelden und werden mit "personalisierten" Webseiten beglückt und gegebenenfalls beim nächsten Besuch anhand von Cookies wieder erkannt. Ein wichtiges Anwendungsgebiet sind datenbankbasierte Webseiten. Online-Shops beispielsweise nutzen diese Techniken um Produkte, Infos, Preise und Verfügbarkeiten aus Datenbanken einzulesen und in dynamisch generierten Webseiten anzuzeigen. Und sie speichern Kundendaten und Bestellungen (Warenkörbe) in Datenbanken. Bevor wir uns nun den einzelnen serverseitigen Techniken zuwenden, werfen wir erst mal einen Blick auf die technischen Grundlagen: HTTP und Formulare in HTML. Exkurs: Technische Grundlagen - HTTPDer Zugriff eines Browsers auf einen Webserver erfolgt über das "Hypertext Transfer Protocol". Die aktuelle Version 1.1. ist im "RFC 2616" beschrieben: http://www.ietf.org/rfc/rfc2616.txt Das Protokoll HTTP bildet zusammen mit dem HTML-Format die Grundlage des uns bekannten World Wide Web. Da sich das WWW aber anscheinend anders entwickelt hat, als ursprünglich mal angedacht, kann HTTP einerseits mehr als uns lieb ist, hat aber andererseits auch eklatante Schwächen. Werfen wir also einen Blick auf die Arbeitsweise von HTTP. HTTP-RequestDer Webbrowser stellt eine Anfrage an den Webserver, einen sogenannten "HTTP-Request". HTTP ist (wie viele Internet-Protokolle) ein textbasiertes Protokoll. Das heisst, mit geeigneten technischen Hilfsmitteln kann man den Datenverkehr beobachten und im Klartext mitlesen. Eine typische (allerdings für unserer Zwecke stark vereinfachte) Anfrage eines Browser an einen Webserver könnte wir folgt aussehen:
In der ersten Zeile teilt der Browser mit, dass er vom Server gerne die Datei "/demo.php" abrufen möchte. Die zweite Zeile mit der Host-Angabe ist immer dann notwendig, wenn es sich bei der Webpräsenz um einen virtuellen Webserver handelt, sich also viele solche Webpräsenzen einen Rechner und dessen IP-Adresse teilen. Anhand des HOST-Eintrags weiss der Server dann, welche Präsenz gemeint ist. Mit dem Kommando "GET" können Dokumente beliebigen Typs (HTML, Audio, Bilder, ...) von einem Webserver abgerufen werden. Wenn der HTTP-Zugriff über einen Proxy erfolgt, dann schickt der Browser auch die Angaben zu Protokoll und Host in der GET-Zeile mit. Der Proxy selber wiederum wendet sich dann wie oben geschildert an den Host:
Neben "GET" gibt es noch eine Reihe weiterer Befehle. So können mit "HEAD" verwaltungstechnische Infos (Größe in Bytes, Datum der letzten Änderung) zum angegebenen Dokument angefordert werden, ohne dass das Dokument selber dabei mitgeschickt wird. So kann der Browser z.B. feststellen, ob sich das gewünschte Dokument gegenüber dem letzten Zugriff überhaupt geändert hat. Ist dies nicht der Fall, kann eine eventuell aufwendige Neuübertragung vermieden werden, indem einfach die beim letzten Zugriff zwischengespeicherte Version aus dem "Cache" genommen wird. Mit "POST" können Daten an den Server geschickt werden, z.B. Feldinhalte aus einem ausgefüllten Formular oder Dateianhänge beim E-Mail-Versand per Web. Mit "PUT" können (theoretisch) Dokumente auf den Server hochgeladen oder mit "DELETE" dort gelöscht werden. Die letzten beiden Befehle dürften allerdings bei den meisten ordentlich verwalteten Webservern nicht so ohne weiteres möglich sein :-) . Weitere hier nicht näher zu beleuchtende HTTP Kommandos sind "TRACE", "OPTIONS" und "CONNECT". Für nähere Informationen sei nochmals auf die RFC 2616 verwiesen. HTTP-ResponseNormalerweise antwortet der Server auf einen HTTP-Request mit einer sogenannten HTTP-Response (hier ebenfalls wieder stark vereinfacht):
Eine HTTP-Response besteht prinzipiell aus einer oder mehreren sogenannten Headerzeilen, einer trennenden Leerzeile und den zu übertragenden Daten, also dem HTML-Code, Grafikdatei, etc.. In der Headerzeile unseres Beispiels teilt der Server mit, dass der nachfolgende Inhalt eine HTML-Datei ist: "Content-type: text/html". Diese Typ-Angaben sind die auch schon von der E-Mail her bekannten MIME-Types (siehe "E-Mail inside"). Nach der trennenden Leerzeile folgt dann unser kleiner HTML-Gruß an die Welt. Wie bereits angedeutet, hat HTTP (jedenfalls bei bestimmten Anwendungen) neben seinen Stärken auch Schwächen. HTTP ist nämlich ein "statusloses" Protokoll. Das heisst in etwa, dass jeder HTTP-Zugriff für sich allein steht. Bei HTTP Version 1.0 erfolgt jeder einzelne Abruf in einer eigenenen jeweils auf- und wieder abzubauenden TCP/IP-Verbindung. Besteht eine Webseite nun aber nicht nur aus einem HTML-Dokument, sondern hat auch noch z.B. dreissig eingebettete Bildchen (GIFs), so sieht man deutlich, dass es nicht ganz optimal sein kann, die Verbindung stets ab- und unmittelbar darauf wieder aufzubauen. Mit HTTP Version 1.1 wird die TCP/IP-Verbindung daher aus Effizienzgründen für mehrere nacheinander erfolgende Zugriffe genutzt und nach dem letzten Abruf einer Folge wieder geschlossen. (Für Puristen und Besserwisser: der geschilderte Unterschied zwischen HTTP 1.0 und 1.1. betrifft natürlich erstmal nur das Default-Verhalten. Sowohl bei HTTP 1.0 als auch bei HTTP 1.1 kann das jeweils andere Verhalten durch die Direktiven "connection: keep-alive" bzw. "connection: close" erzwungen werden.) Während die Steuerung des Auf- und Abbaus von TCP/IP-Verbindungen allenfalls geeignet ist, die Performance zu verbessern, ist hiermit aber noch nicht erreicht, dass der Webserver die verschiedenen Zugriffen eines bestimmten Benutzers von denen anderer Benutzer unterscheiden kann. Auch die IP-Adresse des Kommunikationspartners ist hierfür nicht geeignet. Es könnte sich ja beispielsweise um den Proxy-Server einer großen Firma oder eines Providers handeln, über den hunderte von Zugriffen verschiedender Nutzer gleichzeitig erfolgen. Oder mehrere Leute teilen sich einen DSL-Anschluss mit Flatrate, etc. Will man nun aber einem Benutzer eine "personalisierte" Webseite oder seinen eigenen Warenkorb präsentieren, so muss man irgendwie in der Lage sein, seine Zugriffe von denen anderer Benutzer mit hinreichender Sicherheit zu unterscheiden, um jedem die jeweils richtigen Inhalte zu präsentieren. Hierzu vergibt man sogenannte Session-IDs, die es erlauben, die Zugriffe verschiedener Benutzer voneinander zu unterscheiden. HTTP kennt so etwas wie "Sessions" aber erstmal nicht. Hier gibt es nur einzelne Abrufe, die nichts weiter miteinander zu tun haben. Das liegt einfach daran, dass HTTP ursprünglich wohl nur dazu gedacht war, Dokumente zu transportieren. E-Commerce, Warenkörbe oder personalisierte Webseiten waren offenbar definitiv nicht geplant. Um dennoch "Sessions" unterscheiden zu können, muss eine der nachfolgend geschilderten Techniken genutzt werden. Session-IDs in der URLSession-IDs können z.B. als Parameter in der URL von Seitenaufruf zu Seitenaufruf mitgeschleppt werden, etwa so:
Abgesehen davon, dass es oft nicht wünschenswert ist, dass die Session-ID so offen sichtbar ist, ist dieses Verfahren auch recht aufwendig, weil jeder einzelne interne Link dynamisch so geändert werden muss, dass er um den Parameter Session-ID ergänzt wird. Tippt der Besucher eine URL dann selber ein, findet dieser Abruf nicht mehr innerhalb der Session statt, weil die ID fehlt. Session-IDs in der URL sind teilweise auch ein Risiko, da sie zu Experimenten und Manipulationen geradezu herausfordern, im Cache abgelegt werden, eventuell bei Aufrufen von Links an fremde Seiten mitgeschickt werden u.ä. Exkurs "Cookies"Für Session-IDs und ähnliche Informationen wesentlich besser geeignet sind die sogenannten "Cookies". Bei diesen "Keksen" handelt es sich (normalerweise) um kleine Textdateien, die bei HTTP im Headerbereich mitgeschickt werden.
Hier wird versucht, ein Cookie mit dem Namen "sessionid" und dem Wert 47110815 zu setzen. Das Cookie wird vom Server bei seiner Antwort also im Headerbereich der HTTP-Response mitgeschickt. Der Browser entscheidet je nach Konfiguration, ob er das Cookie akzeptiert oder nicht. Wenn er es annimmt, dann merkt er sich, woher er das Cookie bekommen hat und speichert es. Bei allen folgenden Zugriffen auf denselben Server wird der Browser das Cookie mit seiner Anfrage automatisch im Headerbereich des HTTP-Requests mitschicken. Der Server erkennt dann den Benutzer an Hand dieses Cookies, das z.B. eine Session-ID enthalten kann.
Diese Beispiele sind (wie alle Darstellungen hier) stark vereinfacht. In Wirklichkeit haben Cookies auch noch ein Verfallsdatum und können bestimmten Domänen und Unterverzeichnissen zugeordnet werden. Viele Websites finanzieren sich durch Werbung, die von speziellen Werbeservern geholt und eingeblendet wird. So kann es vorkommen, dass ich im Laufe der Zeit z.B. zwanzig verschiedene Websites besuche, die alle den gleichen Werbepartner haben. Jedesmal werden Werbebanner eingeblendet, d.h. mein Browser nimmt Kontakt mit diesem Server auf. Habe ich nun beim ersten Besuch ein Cookie vom Server erhalten, bin ich für ihn auch dann erkennbar, wenn ich von einer ganz anderen Website her komme. Nun ist es dem Werbeserver also möglich, ein Profil über mein Surfverhalten anzulegen. Eventuell habe ich sogar bei einem meiner Besuche irgendwo meine E-Mail- oder Post-Adresse hinterlassen (um z.B. bei einem Gewinnspiel mitzumachen) und schon ist es vorbei mit der Anonymität. Zur Ehrenrettung der Cookies sei unbedingt noch erwähnt, dass sie nun wirklich keine Viren oder ähnliches übertragen und dass sie eigentlich schon recht nützlich sind. Es kommt halt darauf an, wer sie zu welchem Zweck setzt. Eventuell sollte man erwägen, seinen Browser so einzustellen, dass alle Cookies beim Schließen des Browsers verfallen. So sind zwar Sessions per Cookie möglich, aber eben keine länger andauernden Profilbildungen. Cookie - TestscriptHier findet sich ein kleines PHP-Skript, mit dem Cookies gesetzt, angezeigt und gelöscht werden können. Viel Spaß! Und hier ist der Sourcecode des Cookie-Programms:
Zu Beginn des Programms wird geprüft, ob ein Cookie zu setzen ist (dies ist genau dann der Fall, wenn die Variable $cookie einen Wert enthält, also "gesetzt" ist, bitte nicht verwirren lassen!). Mittels setcookie() wird das Cookie gesetzt (genaugenommen heisst das lediglich, dass eine entsprechende Bitte im Header der HTTP-Response an den Browser übermittelt wird, der entscheidet dann, ob das Cookie gesetzt wird oder nicht!). Weiterhin wird der Browser durch die Direktive "Location" im Header dazu veranlasst, das PHP-Script gleich nochmal aufzurufen, damit das soeben gesetzte Cookie auch sofort in der Liste der Cookies sichtbar wird (netter Trick, oder?). Der Rest des Sourcecodes beschäftigt sich damit, dass das Formular aufgebaut und die Werte mittels "post" versendet werden. Und schliesslich werden auch noch die gesetzten Cookies aufgelistet. Das war's auch schon! Hinweis: Wenn Sie mit Cookies experimentieren, die nur eine Lebenszeit im Sekundenbereich haben, müssen Sie schnell genug sein, sonst sind die schon abgelaufen, bevor Sie sie gesehen haben! Und weiterhin zu beachten ist, dass die Ablaufzeit der Cookies vom Server (nach seiner Uhr) gesetzt werden, aber vom Browser ausgewertet werden. Weichen die beiden Uhren voneinander ab, so gibt es kurzlebige Cookies, die schon beim Eintreffen im Browser abgelaufen sind (netter Effekt!). Exkurs: Formulare in HTMLBevor wir uns gleich näher mit serverseitiger Dynamik befassen, wollen wir uns zuvor noch mal anschauen, wie denn Client und Server interagieren können. Bei lokalen (clientseitigen) Skriptsprachen liegen ja alle Eingaben und Benutzerreaktionen lokal vor, sind für die Skriptsprache also zugänglich. Wie aber weiss das entfernt auf dem Server agierende Programm, was wir von ihm wollen? Hier kommen nun die HTML-Formulare ins Spiel. Jeder hat sie sicher schon mal benutzt, sei es zum Eingeben der eigenen Adresse bei einer Bestellung, für die Eingabe der eigenen E-Mail-Adresse bei der Anforderung von Informationen, bei der Benutzung einer Suchmaschine, beim Login auf einer besonders geschützten Seite, etc. Parameterübergabe mit GETWerfen wir mal einen Blick auf ein typisches Formular: Und so sieht der HTML-Code hierzu aus:
In der ersten Zeile wird mit dem Tag <form> die Definition des Formulars eingeleitet und festgelegt wie und wohin die eingegebenen Formulardaten zu senden sind. In der zweiten und dritten Zeile werden die Eingabefelder definiert, mit einem Namen ("num1" bzw. "num2") versehen, eine eventuelle Vorbelegung und die Feldgröße festgelegt. In der vierten Zeile wird der Button zum Abschicken des Formulars angelegt und mit der Beschriftung "Addiere!" versehen. In der fünften Zeile schließlich endet die Definition des Formulars. Fertig! Wenn wir in die Felder beispielsweise die Werte "333" und "555" eintragen und den Button drücken, wird unser Browser die folgende HTTP-Anfrage verschicken:
Wie wir sehen, werden die Parameter in einer bestimmten Weise an die aufgerufene URL angehängt und mit dem GET-Kommando übermittelt. Tatsächlich können die Formulardaten in dieser Weise auch händisch, d.h. ohne Formular versendet werden: http://hitforum.de/demo.php?num1=333&num2=555 Nicht immer ist es erwünscht, dass die Formulardaten mit der URL sichtbar übertragen werden und so eventuell auf dem Weg zwischen Browser und Webserver in irgendeinem Cache oder Logfile landen. Wer möchte schon gerne, dass beispielsweise Passwörter in irgendwelchen Web- oder Cacheprotokollen zu finden sind. Rufen Sie doch mal Ihre Lieblings-Suchmaschine durch manuelle URL-Eingabe auf und achten Sie dabei darauf, welche alten Aufruf Ihr Browser noch kennt und hilfbereit anbietet. Sein Cache weiss eine ganze Menge über das, was Sie so interessiert :-) . Parameterübergabe mit POSTHier haben wir das gleiche Formular wie oben noch einmal, aber mit einem wichtigen Unterschied: Das Formular sieht genauso aus, den Unterschied kann man nur bei Betrachtung des Sourcecodes feststellen oder wenn man ganz aufmerksam auf die URL-Angabe im Browser nach dem Abschicken des Formulars achtet. Hier ist der HTML-Code:
In der ersten Zeile ist nun als Methode nicht mehr "GET", sondern "POST" angegeben. Das bedeutet nun nicht etwa, dass das Formular per Post verschickt wird, das wäre ja auch viel zu langsam :-). Vielmehr wird der Browser nun folgende Anfrage stellen:
Die Formulardaten werden also nicht mit der URL übertragen, sondern nach der trennenden Leerzeile im "Body" der Anfrage. Das hat nicht nur den Vorteil, dass sie hier nicht ganz so leicht einzusehen oder manipulieren sind. Im "Body" lassen sich auch Datenmengen übertragen, die in der URL beim GET nicht mitgeschickt werden könnten, z.B. Dateien für einen Upload vom Client auf den Server. Wenn Sie sich eingehender mit HTML und seinen Möglichkeiten beschäftigen möchten, dann empfehle ich Ihnen, sich mal SelfHTML näher anzuschauen: www.netzwelt.com/selfhtml/ Der Selfhtml-Autor Stefan Münz hat zusammen mit Wolfgang Nefzger im Franzis-Verlag eine HTML-Bibel mit über 1900 Seiten in zwei Bänden veröffentlicht: "HTML & Web-Publishing Handbuch" ISBN 3-7723-7515-4, 1312 Seiten, Eur 69,95, Themen: HTML - JavaScript - CSS -DHTML "HTML & Web-Publishing Handbuch" ISBN 3-7723-7516-2, 592 Seiten, Eur 39,95, Themen: XML - DTDs - Perl/CGI) Oder als Doppelpack unter der ISDN 3-7723-0598-9 für Eur 79,95
Ebenfalls empfehlenswert ist das Buch von Günter Born "HTML Kompendium" Günter Born bietet ein HTML-Tutorial und eine HTML-Referenz zum Download an: Bei Lycos gibt es einen Workshop über HTML: Beispielprogramm zur Parameterübergabe mit GET und POSTFür weitere Versuche mit den Methoden "GET", "POST" und alternativ mit JavaScript hier ein Link zu unserem Beispiel-Formular und der zugehörige Quelltext. Man beachte, dass hier das bei "action" angegebene Ziel-Dokument identisch mit dem Formular-Dokument ist! Dies ist durchaus üblich und bietet etliche Vorteile. So braucht man sich nicht mit zwei irgendwie zusammengehörenden Dokumenten herumschlagen und kann bei fehlerhaften Eingaben direkt das Formular (eventuell mit rot-markierten Hinweisen) erneut ausgeben.
Technischer Ablauf bei serverseitiger DynamikAber zurück zur Technik. Der bisher geschilderte Ablauf stimmt so für statische Dokumente. Soll uns der Server jedoch dynamisch erzeugte Inhalte liefern, sieht es wie folgt aus:
Der Client fordert ein Dokument per HTTP-GET oder HTTP-POST an (1.). Bei entsprechender Konfiguration wird der Webserver (2.) das angeforderte Dokument nun aber nicht einfach unverändert an den anfragenden Browser schicken. Vielmehr wird er dessen Inhalt an ein externes Programm oder ein im Webserver integriertes Modul zur weiterreichen (3.), dort wird der aktive Inhalt ausgeführt (4.), das Ergebnis an den Webserver zurückgegeben (5.) und von diesem an den anfragenden Browser zurückgeschickt (6.). Common Gateway Interface (CGI)Die älteste und wohl auch bekannteste Schnittstelle zwischen Webserver und externen Programmen ist das Common Gateway Interface (CGI). Typische CGI-Aufrufe sehen in der URL wie folgt aus: www.hitforum.de/cgi-bin/login.pl?name=bill+gates&pw=geheim Über CGI kann ein externes Programm gestartet und mit Daten versorgt werden. Im angegebenen Beispiel wird der Webserver durch entsprechende Konfiguration erkennen, dass die Datei login.pl per CGI an den Perl-Interpreter zu übergeben ist. Dem externen Programm (hier der Perl-Interpreter) werden alle notwendigen Parameter per Environment-Variablen oder über seine Standardeingabe mitgeben. Die Ausgabe des Programms wird von dessen Standardausgabe abgeholt und an den anfragenden Browser zurück gesendet. Mittels CGI kann ein beliebiges externes Programm eingebunden werden. Dieses muss so gut wie nichts über HTTP und den Webserver wissen. Es muss lediglich in der Lage sein, die Environment-Variablen und seine Standardeingabe auszulesen und etwas sinnvolles (d.h. den Konventionen entsprechendes) auf die Standardausgabe zu schreiben. Hier können genauso gut selbst geschriebene C- oder Pascal-Programme, Shell-Aufrufe und ähnliches mehr zum Einsatz kommen. Die Ausgabe des Programms kann eine HTML-Datei, eine GIF-Grafik, eine Wave-Datei oder dergleichen mehr sein. Lediglich die passenden HTTP-Header-Zeilen (einschliesslich der trennenden Leerzeile) sind der eigentlichen Ausgabe voranzustellen. Das ist alles. Der Webserver reicht diese Ausgabe dann an den anfragenden Browser weiter, als hätte der den Inhalt ganz konventionell aus seinem Dateisystem ausgelesen. Buchtipp: CGI Kurz und Gut PerlPerl ist eine Skriptsprache, die gerne zusammen mit CGI genutzt wird, aber nicht auf diesen Einsatzzweck beschränkt ist. Perl wurde von Larry Wall als "Practical Extraction & Report Language" entwickelt, also eigentlich als Listenauswertungs- und Reporterstellungssprache. Aber sehr schnell ist daraus eine vollwertige Skriptsprache für verschiedenste Einsatzzwecke geworden.Beipielsweise wird Perl häufig auch von Systemadministratoren zur Vereinfachung ihrer täglichen Arbeit genutzt. Perl tritt also definitiv auch ausserhalb von Webservern auf .-) . Für den Einsatz mit Webservern, CGI und dem textbasierten Protokoll HTTP eignet sich die Sprache Perl dennoch, insbesondere aufgrund ihrer Fähigkeiten zur Textverarbeitung. So hat Perl beispielsweise eine sehr mächtige Engine für reguläre Ausdrücke. Durch die riesige Sammlung von Modulen im CPAN (Comprehensive Perl Archive Network) werden alltägliche CGI-Aufgaben vereinfacht. Z.B. stellt das gleichnamige Modul CGI eine objektorientierte Schnittstelle für den Zugriff auf die GET- und POST-Parameter zur Verfügung. Für fast jeden denkbaren Einsatz gibt es bereits eine vorhandene Lösung. Die Perl-Syntax (siehe unser Beispiel) ist Geschmackssache. Manche lieben sie, andere können sich nicht damit anfreunden. Das soll hier aber nicht weiter unser Thema sein :-) . Da Perl nicht speziell für den Einsatz im Web geschaffen worden ist, müssen häufig spezielle Module für bestimmte Aufgaben installiert werden. Wenn man nicht selber Herr über den Server ist, weil man z.B. lediglich Webspace mit der Möglichkeit zu eigenen Perl-Programmen bei einem Provider nutzt, so hat man meist keine Kontrolle über die zur Verfügung stehenden Module. Dies kann den Einsatz schon durchaus mal erschweren. Hat man aber die volle Verfügungsgewalt über das System, wird die Flexibilität von Perl zu einer nicht zu verachtenden Stärke. Unser Beispielprogramm erzeugt eine HTML-Seite mit der Auflistung aller vorhandenen Environment-Variablen. Man beachte, dass HTML hier lediglich als Ausgabe von perl auftritt und vergleiche das mit den nachfolgend beschriebenen Techniken. In der ersten Zeile muss als Kommentar der Pfad zum Perl-Interpreter auf dem Webserver angegeben werden. Im weiteren Verlauf werden die HTTP-Headerzeilen ausgegeben, dann schliesslich die dynamisch erstellte HTML-Seite. "ENV" ist eine Liste, die alle Environmentvariablen mit Namen und Wert enthält.
Homepage "perl.org": Comprehensive Perl Archive Network: Perl bei O'Reilly: Kostenloser Perl-Interpreter für Windows: Environment VariablenUnter hitforum.de/test/ kann ein Testprogramm aufgerufen werden, das ebenfalls in Perl geschrieben ist und die wichtigsten Environment-Variablen zurückliefert. Damit können wir uns einen Überblick verschaffen, was ein Webserver so alles über uns weiss. Die Ausgabe wird ungefähr so oder ähnlich aussehen:
Unser Browser plaudert aus, dass wir etwas mit Excel, Word und Powerpoint-Dateien anfangen können (HTTP_ACCEPT), also wahrscheinlich diese Softwarepakete installiert haben. Unsere bevorzugte Sprache ist deutsch (HTTP_ACCEPT_LANGUAGE), was auch einen internationalen Server dazu bewegen könnte, uns mit deutschen Seiten zu bedienen. Welchen Browser wir nutzen, wird natürlich auch mitgeteilt (HTTP_USER_AGENT), damit uns der Server angepassten HTML- oder JavaScript-Code liefern kann. Unsere IP-Adresse (REMOTE_ADDR) und den Namen des Rechners (REMOTE_HOST) bzw. die des genutzten Proxys sieht der Webserver, gegebenenfalls auch noch die tatsächliche Adresse für die der Proxy tätig wurde (HTTP_X_FORWARDED_FOR). Und dann verraten wir auch noch, von welcher Seite wir herkommen (HTTP_REFERER). So kann der Webmaster feststellen, ob seine Besucher von einer Suchmaschine vorbeigeschickt worden sind oder ob eine befreundete Site sie hergeleitet hat. Server Side IncludesWie wir gesehen haben, wird beim Einsatz von CGI/Perl das durch die URL referenzierte Dokument als Quelltext interpretiert und ausgeführt. Das Perl-Programm erzeugt dann die HTML-Seite (wenn denn eine zurückgegeben werden soll) als Ausgabe. Ein ganz anderer Ansatz wird nun bei den Server Side Includes verfolgt. Hier enthält das durch die URL referenzierte Dokument bereits den HTML-Code, der auch ausgegeben werden soll. Lediglich an bestimmten Stellen sind in den HTML-Code dynamische Teile eingebettet. Nur diese werden zur Ausführung gebracht und durch ihre jeweiligen Ausgaben ersetzt. Echte Perl-Freaks werden es zwar bestreiten (zumal es in Perl durchaus auch Konstrukte gibt, so etwas nachzubilden) aber grundsätzlich ist das schon ein Unterschied und der SSI-Ansatz durchaus leichter lesbar. Übrigens nutzen alle weiteren noch vorzustellenden Verfahren, wie PHP, ASP, JSP, etc. ebenfalls den Ansatz mit dem "embedded code", an dieser Idee muss also wohl was dran sein :-) ! Wie sieht denn nun ein solcher durch SSI angereicherter HTML-Code aus?
Wie wir sehen, sind die Server Side Includes alle in HTML-Kommentare eingeschlossen und durch ein vorgestelltes "#"-Zeichen markiert. Allerdings wird man als normalsterblicher Surfer diesen Code so niemals sehen, da er eben bereits serverseitig gegen die entsprechenden Ausgaben ausgetauscht wird. Nähere Infos zu SSI gibt es unter anderem hier: SSI Commands: SSI Features: PHPPHP steht für "PHP Hypertext Preprocessor". Wer weiss, dass GNU für "GNU is Not Unix" steht, wundert sich nicht mehr über Abkürzungen, deren erster Buchstabe für die Abkürzung selber steht :-) . PHP ist eine sehr, sehr leistungsfähige Skriptsprache, die in letzter Zeit zunehmend beliebter wird, insbesondere in der Kombination "Linux - Apache - mySQL -PHP" kurz auch "LAMP" genannt. Hier gibt es auch durchaus den einen oder anderen Provider, bei denen man für ein paar Euro im Monat PHP4 und mySQL zur Verfügung gestellt bekommt und sich in einer Sandbox austoben kann. PHP ist insbesondere dem Einsteiger zu empfehlen. Schauen wir uns mal ein kurzes PHP-Beispiel an:
Der PHP-Code wird hier also in einem speziellen Tag <?php... ?> eingeschlossen, die Ausgaben in den HTML-Code eingebettet. Mehr zu PHP gibt es unter anderem hier: SelfPHP (Referenz): PHP Hypertext Processor: PHP/mySQL-Workshop bei Lycos: Jede Menge Infos zu PHP (englisch), u.a. auch ein Tutorial und noch mehr Stoff zu PHP JSP - Java Server PagesJava ist uns ja bereits im Zusammenhang mit clientseitiger Dynamik begegnet. Selbstverständlich kann Java auch serverseitig genutzt werden. Man spricht dann nicht von "Applets" sondern logischerweise von "Servlets". Mit "Java Server Pages (JSP)" steht nun eine Technologie zur Verfügung, die die Nutzung von serverseitigem Java und HTML verbindet. Hier werden (wie auch schon bei PHP und anderen Lösungen) die Servlet-Aufrufe direkt in den auf dem Server vorliegenden HTML-Quelltext eingebettet und die Servlet-Ausgaben fliessen direkt in den an den Browser geschickten HTML-Codes ein. Zum Thema Java Server Pages gibt es viele brauchbare Informationen im Web, so dass wir uns hier vorläufig erstmal mit einem Beispiel und ein paar Links begnügen. Wir hoffen, dieses Thema in nächster Zeit noch weiter vertiefen zu können, dann wird es auch hier neuen Lesestoff geben!
Im Rahmen des Jakarta-Projekts der Apache Software Foundation gibt es Tomcat, eine frei verfügbare Implementation, mit der Servlets und JSP (zum Beispiel zusammen mit dem Apache Webserver) genutzt werden können: JSP bei Sun: Java Server Pages Technology: What is a JSP Page? (Tutorial) Syntax Reference: Java Server Pages Uni Linz Skript zu JSP: Buchtipp JSP: Buchtipp JSP: ASP - Active Server PagesActive Server Pages sind, wenn man so will, die JSP-Version von Microsoft, bzw. umgekehrt, je nach Weltanschauung :-). Bei ASP können nahezu beliebige Skriptsprachen zum Einsatz kommen (auch Perl). Aber die Haus -und Hof-Skriptsprache von Microsoft ist und bleibt VBscript, das auf Visual Basic basiert. Auch hier müssen bis auf weiteres erst einmal ein Beispiel und einige Links genügen:
ASP-Beispiele und weitere Links: ASP - FAQ: Deutsche ASP-Beschreibung ASP-Quellcode-Beispiel: ASP-Seminar: CFM - Cold FusionSeit Anbeginn dabei und noch lange nicht ausgeschieden! Im Gegenteil, jetzt gibt es neu ColdFusion MX. Ein Cold Fusion System ist sozusagen ein eigener Application-Server mit vielfältigen Möglichkeiten. Auch hier nur kurz der Ausriss aus einem Beispiel und eine Handvoll Links:
Philipp Cielen / Steffen Goldfuss / Christoph Schmitz Charles Mohnike: ColdFusion in 21 Tagen Link zum Hersteller macromedia (früher Allaire): Cold Fusion Portal Cold Fusion User Group Application ServerMit den "Application Server" sind wir definitiv in der Business Class angekommen. Wir halten dieses Thema für so wichtig und interessant, dass wir demnächst hierzu einen eigenen Termin einplanen wollen. Danach wird es auch hier mehr zu diesem Thema geben. Für jetzt erstmal in aller Kürze: Application Server sind eigenständige, vom Webserver unabhängige Server, die zum Beispiel Java-Code ausführen und hier alle nur denkbaren Möglichkeiten bieten. Vorteil der Trennung von Web- und Application-Server ist u.a. dass die Systeme besser skalieren, also dem Leistungsbedarf angepasst werden können, beispielsweise durch Einsatz einer ganzen Server-Farm und Loadbalancing. Hierdurch können hoch performante, hoch verfügbare Lösung erstellt werden. Große und größte Websites werden mit dieser Technologie realisiert. Stichworte in diesem Umfeld sind J2EE (Java 2 Enterprise Edition), Java Beans, CORBA bzw. DCOM. Im Hintergrund sind meist auch noch diverse Datenbanken im Spiel. Insgesamt also keine billige Lösung, aber eben das, was in der Profiklasse eingesetzt wird :-). Application Server gibt es von so gut wie jedem der Big Player im Markt und von etlichen (kleineren) Spezialisten. Der große Vorteil beim Einsatz von Java ist natürlich die Kompatibilität über verschiedenste Plattformen hinweg. Nun ja, in der Realität muss man das dann leider doch wieder etwas einschränken. Sobald irgend eines der verlockenden, netten, aber leider sehr speziellen Features genutzt wird, durch die sich die verschiedenen Application Server unterscheiden, ist es natürlich wieder aus mit dem "write once - run everywhere". Wir freuen uns schon darauf, dieses Thema demnächst (2. Hälfte 2002) zu vertiefen. Bis dahin erstmal ein paar Links zum Thema: Einen Überblick über Application Server, Web Services, SOAP und Java liefert J2EE-Application Server - Grundlagen und Marktübersicht Middleware - Application Server - IT-Welten in Verbindung SicherheitsaspekteWie schon erwähnt, sind aktive Inhalte aus Sicherheitsgesichtspunkten nicht ganz unbedenklich. Kurz gesagt, tritt das Problem dabei generell auf der Seite auf, auf der der Code aktiv ist. Das heisst also, bei clientseitiger Dynamik ist gegebenenfalls der Rechner des "Surfers" gefährdet, bei serverseitiger Dynamik der Webserver. Trotz aller Sicherheitsbarrieren kommt es immer wieder zu Sicherheitsverletzungen. Teilweise liegt das daran, dass die entsprechenden Programme Sicherheistlücken enthalten. Ein Server ist vielleicht anfällig gegen gezielte Pufferüberläufe, ein Plugin erlaubt Zugriff auf eigentlich geschützte Bereiche oder Angriffe werden geschickt verpackt und an der Firewall vorbei geschmuggelt. Die folgenden Links sollen einen kurzen Überblick über die Gefährdungen geben. Beim BSI (Bundesamt für Sicherheit in der Informationstechnike) findet sich dieser empfehlenswerte Artikel:
Ausführbare Inhalte - Sicherheitsrisiken und Lösungen Weiterhin gibt es beim BSI zum Thema auch noch diese Studie hier (sie ist zwar schon von 1999 aber trotzdem nicht minder aktuell): Aktive Inhalte aus der Sicht eines Firewall-Herstellers Aktive Inhalte und ihre Gefahren (Java, ActiveX, JavaScript) Was sind aktive Inhalte und wie sieht es mit dem Thema Sicherheit aus? Die Deutsche Vereinigung für Datenschutz (DVD) e.V. führt eine "Schwarze Liste" von Webseiten, die ohne JavaScript, ActiveX, Cookies o.ä. nicht genutzt werden können. Links zum ThemaEine sehr gute Einführung in das Thema "Aktive Inhalte im Web" bietet Dieser Artikel passt ganz gut zum Thema | ||||||||||||||||||||
| BUCHTIPPS Rezensionen unserer Leser |