Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
1 Einleitung
2 Webbrowser
3 JavaScript einbauen
4 Programmieren mit JavaScript
5 Datum
6 Zufall
7 Browserinformationen
8 Fenster
9 Formulare
10 Frames und Iframes
11 Grafiken
12 Cookies
13 Objekte und Arrays
14 Ereignisbehandlung
15 Fehlerbehandlung
16 DOM
17 DHTML und CSS
18 AJAX
19 XML
20 Web Services
21 AJAX-Frameworks
22 Plugins
23 Multimedia
24 Java
25 Serverseitige Technologien
26 JavaScript goes .NET
27 Code schützen
28 Top Secret: Passwortschutz
29 Signierte Skripte
30 JavaScript und Sicherheit
31 Navigation
32 Warenkorb
33 JavaScript-Bibliotheken
34 Referenz
35 Quellen im Web
36 Die Zukunft von JavaScript
Index
Download: - ZIP, ca. 9,2 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> / JavaScript und AJAX | vor >>
JavaScript und AJAX von Christian Wenz Das umfassende Handbuch
JavaScript und AJAX 839 S., mit DVD, 39,90 Euro Galileo Computing ISBN 3-89842-859-1 |
| Kapitel 12 Cookies
|  | 12.1 Was ist ein Cookie?
|  | 12.2 Wie sieht ein Cookie aus?
|  | 12.3 Cookies mit JavaScript
|  |  | 12.3.1 Cookies setzen
|  |  | 12.3.2 Cookies löschen
|  |  | 12.3.3 Cookies lesen
|  |  | 12.3.4 Cookie-Unterstützung überprüfen
|  |  | 12.3.5 Ein Cookie statt vieler Cookies
## 12.2 Wie sieht ein Cookie aus? Ein Cookie erinnert an den Versand eines Formulars via GET. Jeder Cookie hat als Hauptkomponente (mindestens) ein Name-Wert-Paar. Auch hier gelten wieder die üblichen Regeln der URL-Codierung, also heißt es Autor=Christian+Wenz oder Autor=Christian%20Wenz, weil das Plus-Zeichen oder hexadezimal 20 (dezimal 32) das Leerzeichen ersetzt. Außerdem hat ein Cookie noch die folgenden weiteren, optionalen Parameter in Form von Name-Wert-Paaren:
| domain: Dieser Parameter bezeichnet die Domain des Servers, der den Cookie lesen darf. Standardmäßig ist das der Server-Anteil der URL der Seite, die den Cookie setzt. Dieses Attribut wird jedoch unter bestimmten Umständen anders gesetzt. Angenommen, eine Firma hat mehrere Webserver, server1.firma.de, server2.firma.de und www.firma.de. Von jedem dieser Server aus soll ein Cookie gelesen werden können. Standardmäßig wäre der domain-Wert des Cookies, wenn er auf www. firma.de/cookie.htm gesetzt worden ist, www.firma.de; als direkte Konsequenz hätten server1.firma.de und server2.firma.de keinen Zugriff auf diesen Cookie. Um dies zu vermeiden, kann das domain-Attribut gesetzt werden. Es würde in diesem Fall auf .firma.de gesetzt, wodurch jeder Server, dessen Name auf .firma.de endet, den Cookie lesen kann. Ein Domainname muss hier mindestens zwei Punkte enthalten, deswegen steht ein Punkt vor firma.de. Einige Leute sind auf die Idee gekommen, einfach die Cookies mehrerer (unterschiedlicher) Seiten auf einem zentralen Cookie-Server zu speichern. Beim Netscape Navigator gibt es eine Option, die dies vereitelt (Bearbeiten N Einstellungen N Erweitert N Nur an den ursprünglichen Server zurückgesendete Cookies akzeptieren). Pro Domain werden übrigens nur 20 Cookies akzeptiert, danach werden alte Cookies gelöscht bzw. überschrieben.
| expires: Jeder Cookie hat ein Ablaufdatum, nach dem er gelöscht wird. Manche Seiten setzen dieses Datum auf das Jahr 2037 oder später, und so lange wird die Festplatte des Benutzers sicher nicht halten – es sind also (beinahe) unendlich lange gültige Cookies möglich. Eine Sicherheit, dass der Cookie tatsächlich so lange hält, hat man indes nicht, da Cookies manuell oder durch Überschreitung der 300er-Grenze vom Netscape Navigator gelöscht werden können. Wird kein Ablaufdatum angegeben, so wird der Cookie gelöscht, sobald der Browser beendet wird. Man spricht hier von einem Session-Cookie oder einem temporären Cookie; Cookies mit gesetztem Ablaufdatum nennt man permanente Cookies. Das Ablaufdatum sollte im GMT-Format angegeben werden; in JavaScript ist das ein Fall für die toGMTString()-Methode.
| path: Wie oben ausgeführt wurde, kann ein Cookie von demjenigen Server ausgelesen werden, der in der domain-Eigenschaft angegeben ist. Wenn wichtige Daten in Cookies gespeichert werden, gibt es jedoch unter Umständen ein Problem. Wenn Sie bei Ihrem ISP eine Website hosten lassen, haben Sie oft eine URL der Bauart mitglied.isp.de/mitgliedsname. Die Seite des Konkurrenten, die auch bei diesem ISP gehostet wird, hat die URL mitglied.isp.de/nocheinmitglied. Die Domain ist jedoch in beiden Fällen mitglied.isp.de – und damit kann die Website Ihres Konkurrenten die Cookies lesen, die Ihre Seite bei dem Benutzer gesetzt hat (wenn der Benutzer zuerst Ihre Seiten und dann die der Konkurrenz besucht). Aus diesem Grund kann man noch einen Pfad setzen. Nur Webseiten, die in diesem Pfad auf dem entsprechenden Server liegen (Unterverzeichnisse eingeschlossen), können den Cookie lesen. In diesem Fall sollten Sie also den Pfad Ihrer Cookies auf /mitgliedsname setzen, um böse Überraschungen zu vermeiden. Ein weiteres Beispiel: Der Standardwert von path ist das Verzeichnis der Datei auf dem Webserver, die den Cookie setzt. Wenn Sie den Cookie aber auf jeder anderen Seite, auch in anderen Verzeichnissen, lesen wollen, sollten Sie den Wert von path auf / setzen.
| secure: Diese Eigenschaft muss nur angegeben werden; hier liegt kein Name-Wert-Paar vor. Ist die Eigenschaft gesetzt, so darf der Cookie nur gelesen werden, wenn man über eine HTTPS-Verbindung, also über eine »sichere«, verschlüsselte Verbindung mit der Webseite verbunden ist.
Die Parameter bzw. Name-Wert-Paare werden durch Semikolon und Leerzeichen voneinander getrennt. Ein typischer Cookie sieht also folgendermaßen aus:
    Autor=Christian+Wenz; domain=.galileo-press.de; expires=Sun, 01-Oct-2006 12:00:00 GMT; path=/; secure
Der Name des Cookies ist gleichzeitig der Identifikator, es darf also nicht zwei Cookies mit demselben Namen geben. Wird ein Cookie gesetzt, den es (vom Namen her) schon gibt, wird der alte durch die neuen Daten überschrieben. Nur wenn der Pfad unterschiedlich ist, kann man denselben Namen öfter verwenden. Dieses Vorgehen ist jedoch nicht empfehlenswert – und auch mit JavaScript schwer zu fassen. Das Setzen ist einfach, aber das Lesen gestaltet sich schwierig.
<< zurück | <top> | vor >>
Zum Katalog
JavaScript und AJAX bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchtipps
| JavaScript und AJAX - Das Video-Training
| Webseiten programmieren und gestalten
| XHTML, HTML und CSS
| CSS-Praxis
| AJAX
| PHP 5 und MySQL 5
| TYPO3 4.0
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press 2007
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de