Mailinglisten-Archive |
Wolfgang Huebner wrote: > > Im Moment hältst Du User davon ab, überhaupt abzustimmen, wenn Sie > > von einer großen Site kommen. Du testet für das falsche Feature (Nicht > > "Wer bist Du?", sondern "Woher kommst Du?") und erzeugst so eine > > Und genau dieses "Wer bist Du?" läßt sich auch mit Cookies nicht eindeutig > feststellen. Es ist eine wesentlich bessere Methode als mit IP-Nummern zu arbeiten, denn es setzt einige Schichten höher im Protokollstack an. IP-Nummern sind ein Schicht-4 Feature, sie werden für Interfaces von Maschinen vergeben - Du schlägst vor, sie für die Prüfung von Identitäten von Personen zu verwenden. Das führt zu den Anomalien, die ich aufgezählt habe und die Dir ja bekannt sind. Diese Anomalien sind aber, wenn man sein Serverlog man anaysiert, der Regelfall und nicht die Ausnahme (oder wieviele Zugriffe von *.t-online.de, *.aol.com und so weiter siehst Du pro Minute auf Deinem Server?). Cookies identifizieren immerhin den Browser des Anwenders, was eine wesentlich bessere Zuordnung von tatsächlichen Personen zu beobachteten Identitäten zuläßt als Interfaces von Maschinen - die Auflösung ist um ein Vielfaches höher und Du bist mit Deiner Metrik wesentlich dichter an dem Subjekt, das Du eigentlich messen möchtest. Durch kluge Ausgestaltung der Cookies kannst Du sogar dafür sorgen, daß die Cookies schwer fälschbar werden und zeitlich begrenzt gültig sind. > > Ja. Dafür (einen Benutzer zu identifizieren) sind sie geschaffen > > worden. Wenn ein User ohne Session-ID-Cookie reinkommt, dann kann > > er schlicht nicht abstimmen. Siehe auch die CNN-Polls (www.cnn.com), > > Und was ist mit der zunehmenden Menge an Usern, deren Sysadmins Cookies > schon mit der Firewall oder HTTP-Filtern abblocken? Diese Leute können nicht abstimmen. Sie können außerdem nicht shoppen, keine personalisierten Angebote abrufen, müssen durch längere Loginprozesse bei Webshops wie Amazon und können auf einige Websites gar nicht zugreifen, weil dort der gesamte Inhalt unter einer einzigen URL abrufbar ist und die Navigation vollständig über den an einen Session-Cookie gebundenen Zustand der Anwendung gesteuert wird. > Oder was hindert mich > daran, den Cookie zu löschen und mir sofort einen neuen verpassen zu lassen > (auch evtl. durch ein Programm)? Nichts. Was hindert Dich, die Verbindung zu trennen und Dir eine neue IP-Nummer verpassen zu lassen? Was hindert Dich, unter derselben IP-Nummer mit unterschiedlichen User-Agent-Strings zu senden (Wenn Du Dummuser bist: nimm Star Office als Browser, da kannst Du den UA-String frei eingeben). > Oder was ist, wenn ich meinen Rechner nicht > alleine benutze und ein Mitbewohner 5 Stunden später auch abstimmen möchte? Nichts. Du meldest Dich ab, er meldet sich an, er startet seinen Browser und der hat Cookies, die von Deinen Cookies verschieden sind. > Gibt es noch andere Möglichkeiten, neben IP speichern und Cookies > auszuteilen? Was Du eigentlich versuchst, ist einen Zustand zu speichern ("Der Benutzer hat schon abgestimmt/hat noch nicht abgestimmt") und diesen Zustand an eine Identität einer Person zu binden ("_Dieser_ Benutzer hat...") und - das ist das zentrale Problem dabei - dies gegen den Willen der betreffenden Person zu tun. Je zwei Bedingungen jeweils mit Standardmethoden zu erfüllen: - Zustand speichern, gegen den Willen der Person: Anwendung so gestalten, daß sie wie PHPLIB im cookie/get-Mode läuft. Wenn der Anwender den Cookie annimmt, Zustand mit Cookies binden, sonst als GET-URL weiterlaufen lassen. Navigation so gestalten, daß alle Seiten dieselbe URL haben und die Navigation nur über den gebundenen Zustand der Anwendung möglich ist. Die Abstimm-Seite ist dann nur erreichbar, wenn der Anwender die Navigation mit einem entsprechenden ID-Token als Cookie oder GET-Parameter durchläuft. "Identität feststellen" kann man optional noch draufsetzen, siehe 3. Beispiel. - Zustand speichern, Identität der Person feststellen: Anwendung so gestalten, daß sie wie PHPLIB im cookie/get-Mode läuft, über den Cookie merken, ob der Anwender abgestimmt hat. Cookies fälschungssicher machen: $now = time(); $cookieval = $now . "-" . md5($now.":".$secret); Du kannst jetzt beim betreten der Site einen solchen Cookie setzen, wenn der Anwender noch keinen solchen Cookie hat. Du kannst bei der Abstimmung sehen, von wann der Cookie ist ($now-Komponente isolieren) und prüfen, ob der Cookie von Deiner Anwendung stammt ($now Komponente isolieren, um $secret ergänzen, Prüfsumme berechnen und gegen die MD5-Komponente des Cookies vergleichen. Da nur Deine Anwendung $secret kennt, kann der Anwender seine Cookies selbst nicht signieren und keine Cookies fälschen. "gegen den Willen der Person" geht das nicht, weil der Anwender einfach den Cookie löschen kann und so wieder abstimmen kann. - Identität der Person feststellen, gegen den Willen der Person: Selbstregistrierung erzwingen, Abstimmung nur nach Anmeldung und nur für registrierte User. Anmeldeprozeß ggf. durch Mailfeedback validieren, um automatisierte Anmelder auszuschalten. Kristian -- Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00 Using PHP3? See our web development library at http://phplib.shonline.de/ (GPL)
php::bar PHP Wiki - Listenarchive