Hi, ich bin zurzeit damit beschäftigt ein größeres Webprojekt umzusetzen. Dabei traten bisher aber immer wieder Fehler auf, die nicht wirklich reproduzierbar waren und auch in ungleichen Zeitabständen auftraten. Kurze Vorgeschichte: Um unsere Besucher wiederzuerkennen und ihre Einstellungen zu speichern verwenden wir Cookies. Sobald der Besucher das erste mal die Seite aufruft wird das Cookie "visitor" gesetzt das eine zufällige Zeichenkette (hexadezimal) als Wert hat, das ganze wird auch in einer Datenbank auf dem Server abgelegt. Das funktionierte soweit alles sehr gut, allerdings wurden an manchen Tagen sehr viele Datensätze=neue Cookies generiert, also deutlich mehr als man erwartet hätte. Heute trat dann ein Problem auf: Der Browser eines Bekannten wollte keine Cookies dieser Seite mehr annehmen, nur noch nach dem Löschen der Chronik (Cache, Cookies etc.) hat es wieder funktioniert. In dieser Zeit wurde natürlich immer wieder ein neues Cookie generiert, denn der Besucher war ja "neu" (da kein Cookie gefunden wurde). Wir konnten zwar den Fehler sehen und zeitweise beheben, aber soeben ist er dann bei mir wieder aufgetreten: Cookies werden nicht mehr akzeptiert. ---------------------- Nun zum "technischen": (Sub)Domains: www.asdf.de ist das öffentliche System (natürlich mit ner anderen Domain) (1.Server) login.asdf.de ist ein Bereich für Kunden (1. Server) dev.asdf.de ist das Entwicklungssystem (2. Server!) (Das ist das gleiche System, aber mit eigener Datenbank! Befindet sich auf einem 2. Server) Cookies: visitor mit einem hexadezimalen Wert (einige ZeICHEN) Pfad: / Expires: Etwa ein Monat Domain: .asdf.de (ja der erste Punkt ist lauf RFC2109 nötig, falls der Cookie für ALLE SUBDOMAINS gelten soll. Ist nötig da bei login.asdf.de auch das Cookie von www.asdf.de benötigt wird) Soweit so normal. Viel herumprobieren hat den Fehler nicht behoben, daher habe ich mir mal mit Wireshark den Traffic auf den Servern angesehen. Was ich da gesehen habe ist sehr merkwürdig: Wenn ich zuerst auf dev.asdf.de gehe, dann wird der visitor-Cookie passend gesetzt. Er wird bei den folgenden Anfragen vom Browser auch passend im Header mitgesendet. Jetzt gehe ich auf www.asdf.de Der Browser sendet auch den Cookie dort hin (passt!). Natürlich kann der Server nichts mit dem Cookie anfangen, da er ihn in SEINER Datenbank nicht finden kann. Deshalb generiert er einen neuen und versucht diesen zu setzen. Man sieht dass der Cookie an den Browser zurückgesendet wird. ABER: Nun rufe ich eine weitere Seite auf www.asdf.de auf. Folgendes wird vom Browser an den Server gesendet: ... Cookie: visitor=b730a225bfae6e79cef877bbb0f3b847; visitor=b6b2d5bc2f6fa0c905423928f8179009 ... Wenn das Script dann mit $_COOKIE['visitor'] den Cookie abfrägt erhält es b730a225bfae6e79cef877bbb0f3b847 zurück. Also den ERSTEN Cookie von dev.asdf.de. Der zweite Cookie kommt gar nicht beim Script an, das wäre aber der PASSENDE Cookie von www.asdf.de Was passiert jetzt? www.asdf.de setzt einen neuen Cookie, da er den alten ja nicht finden konnte. Aber jetzt wirds richtig verrückt: Haben wir jetzt 3 Cookies? NEIN! Der ZWEITE Cookie wird durch den neuen Cookie ersetzt. Der ERSTE bleibt erhalten. Irgendwie krank das ganze... Der Fehler tritt übrigens nur im Firefox auf, der Internetexplorer macht hier alles richtig, dieser lässt immer nur einen Cookie mit diesem Namen zu und der alte wird überschrieben. Scheint also so, als wäre der Cookie an die Subdomain gebunden?? Obwohl Domain explizit so gesetzt wurde dass der Cookie zu allen Subdomains gehört! Nun meine Frage dazu: Ist das ein Bug von Firefox oder entspricht das irgendeiner RFC? Denn verständlich ist mir dieses Verhalten vom Firefox nicht. Ich hoffe ich konnte das Problem passend erklären dass es verständlich ist, sonst bitte nachfragen! Danke schonmal für die Antworten!
Johannes O. schrieb: > Hi, > > ich bin zurzeit damit beschäftigt ein größeres Webprojekt umzusetzen. > Dabei traten bisher aber immer wieder Fehler auf, die nicht wirklich > reproduzierbar waren und auch in ungleichen Zeitabständen auftraten. > > Kurze Vorgeschichte: > Um unsere Besucher wiederzuerkennen und ihre Einstellungen zu speichern > verwenden wir Cookies. Sobald der Besucher das erste mal die Seite > aufruft wird das Cookie "visitor" gesetzt das eine zufällige > Zeichenkette (hexadezimal) als Wert hat, das ganze wird auch in einer > Datenbank auf dem Server abgelegt. > Das funktionierte soweit alles sehr gut, allerdings wurden an manchen > Tagen sehr viele Datensätze=neue Cookies generiert, also deutlich mehr > als man erwartet hätte. Das manche Besucher Cookies brutal unterdrücken ist klar? > Heute trat dann ein Problem auf: Der Browser eines Bekannten wollte > keine Cookies dieser Seite mehr annehmen, nur noch nach dem Löschen der > Chronik (Cache, Cookies etc.) hat es wieder funktioniert. In dieser Zeit Es gibt eine Obergrenze wieviele Cookies ein User Agent speichern kann/will. > (Sub)Domains: > www.asdf.de ist das öffentliche System (natürlich mit ner anderen > Domain) (1.Server) > login.asdf.de ist ein Bereich für Kunden (1. Server) > > dev.asdf.de ist das Entwicklungssystem (2. Server!) > (Das ist das gleiche System, aber mit eigener Datenbank! Befindet sich > auf einem 2. Server) > > Cookies: > visitor mit einem hexadezimalen Wert (einige ZeICHEN) > Pfad: / > Expires: Etwa ein Monat > Domain: .asdf.de (ja der erste Punkt ist lauf RFC2109 nötig, falls der > Cookie für ALLE SUBDOMAINS gelten soll. Ist nötig da bei login.asdf.de > auch das Cookie von www.asdf.de benötigt wird) Sowas ist prinzipiell böse... > Soweit so normal. Aua ;-) > Wenn ich zuerst auf dev.asdf.de gehe, dann wird der visitor-Cookie > passend gesetzt. Er wird bei den folgenden Anfragen vom Browser auch > passend im Header mitgesendet. > Jetzt gehe ich auf www.asdf.de > Der Browser sendet auch den Cookie dort hin (passt!). Natürlich kann der > Server nichts mit dem Cookie anfangen, da er ihn in SEINER Datenbank > nicht finden kann. Deshalb generiert er einen neuen und versucht diesen > zu setzen. Man sieht dass der Cookie an den Browser zurückgesendet wird. > ABER: Nun rufe ich eine weitere Seite auf www.asdf.de auf. > Folgendes wird vom Browser an den Server gesendet: > ... > Cookie: visitor=b730a225bfae6e79cef877bbb0f3b847; > visitor=b6b2d5bc2f6fa0c905423928f8179009 Lies mal RFC 6265 (hier 4.1.2, ist zu allem Überfluss nicht-normativ). Was Du da versuchst zu tun ist nicht ordentlich standardisiert, wenn das funktioniert ist das eher Glück. Laut RFC sind Deine zwei "visitor"-Cookies verschiedene Cookies, da Du aber als Domain bei einem davon einen Wildcard definiert hast - passiert halt Mist wenn die Server-Software buggy ist. > Wenn das Script dann mit $_COOKIE['visitor'] den Cookie abfrägt erhält > es b730a225bfae6e79cef877bbb0f3b847 zurück. Also den ERSTEN Cookie von > dev.asdf.de. > Der zweite Cookie kommt gar nicht beim Script an, das wäre aber der > PASSENDE Cookie von www.asdf.de Hmm, hmm, sieht aus wie eine mögliche Interpretation von RFC 6265 4.1.2.3, d.h. meiner Meinung nach kann der Browser das so machen. Dann wäre einfach das Script kaputt. Laut RFC 6265 4.2.2 ist das Script kaputt. Wenn die Programmiersprache mit "multi-valued" Cookies nicht klarkommt ist halt die kaputt (ist das PHP?)... > Was passiert jetzt? www.asdf.de setzt einen neuen Cookie, da er den > alten ja nicht finden konnte. Aber jetzt wirds richtig verrückt: Haben > wir jetzt 3 Cookies? NEIN! Der ZWEITE Cookie wird durch den neuen Cookie > ersetzt. Der ERSTE bleibt erhalten. < > Irgendwie krank das ganze... Wie gesagt, RFC 6265 lesen - soweit ich das überblicke ist das ganz genau was passieren soll. Merke: ein Cookie ist definiert durch "cookie-name, domain-value, and path-value". Zwei Cookies mit domain-value ".foo.de" und "bar.foo.de" sind verschieden und werden beide an "bar.foo.de" gesendet! Keine Wildcards benutzen macht die Sache viel einfacher. > Der Fehler tritt übrigens nur im Firefox auf, der Internetexplorer macht > hier alles richtig, dieser lässt immer nur einen Cookie mit diesem Namen > zu und der alte wird überschrieben. Naja, IE halt.
Jasch schrieb: > Das manche Besucher Cookies brutal unterdrücken ist klar? Ja ist soweit bekannt. Ist aber defintiv nicht die Ursache des Problems. Jasch schrieb: > Es gibt eine Obergrenze wieviele Cookies ein User Agent speichern > kann/will. Kann auch nicht das Problem sein, gibt nur 1 Cookie mit ein paar Zeichen. Jasch schrieb: > Sowas ist prinzipiell böse... Weshalb? Was ist daran schlecht? Wie gesagt: Die Domain (inkl. Subdomain) gehören uns, da hat kein anderer Zugriff drauf, sicherheitstechnisch also unbedenklich. Und dazu haben die Cookiedaten selbst keine wertvollen/geheime Informationen. Jasch schrieb: > Lies mal RFC 6265 (hier 4.1.2, ist zu allem Überfluss nicht-normativ). > > Was Du da versuchst zu tun ist nicht ordentlich standardisiert, wenn das > funktioniert ist das eher Glück. > > Laut RFC sind Deine zwei "visitor"-Cookies verschiedene Cookies, da Du > aber als Domain bei einem davon einen Wildcard definiert hast - passiert > halt Mist wenn die Server-Software buggy ist. RFC sagt: > If the user agent receives a new cookie with the same cookie-name, > domain-value, and path-value as a cookie that it has already stored, > the existing cookie is evicted and replaced with the new cookie. => Die beiden Cookies sind die gleichen. Sie haben den gleichen Namen "visitor", die gleichen Pfad "/" und die gleiche Domain .asdf.de Grundsätzlich funktioniert es aber, dass man, indem man den Cookie einfach neu setzt, der auch beim Browser aktualisiert wird. Liegt auch nicht direkt an der Server-Software, sondern am Browser. Der Server sendet ja nur was das Script ihm befiehlt. Jasch schrieb: > Laut RFC 6265 4.2.2 ist das Script kaputt. Wenn die Programmiersprache > mit "multi-valued" Cookies nicht klarkommt ist halt die kaputt (ist das > PHP?)... Stimmt... In 4.2.2 ist das recht eindeutig beschrieben dass diese Cookies erlaubt sind. Wobei das Problem nicht bei meinem Skript liegt, sondern einfach bei PHP, da es im $_COOKIE Array nur immer ein Cookie pro Namen zulässt. Jasch schrieb: > Wie gesagt, RFC 6265 lesen - soweit ich das überblicke ist das ganz > genau was passieren soll. > > Merke: ein Cookie ist definiert durch "cookie-name, domain-value, and > path-value". Zwei Cookies mit domain-value ".foo.de" und "bar.foo.de" > sind verschieden und werden beide an "bar.foo.de" gesendet! > > Keine Wildcards benutzen macht die Sache viel einfacher. Habs oben schonmal geschrieben, aber genau das ist ja mein Problem: Die beiden Cookies sind wirklich exakt gleich. Darum ist es merkwürdig warum da ein Unterschied gemacht wird. Möglichkeit A wäre: Pro ankommenden set_cookie wird ein Cookie gesetzt. Also erhöht sich die Cookieanzahl immer um 1 pro set_cookie Befehl Möglichkeit B wäre: Der neue Cookie ersetzt den alten Cookie. Das ist die interpretation des Internetexplorers. Der Firefox interpretiert das aber so: Möglichkeit B, solange sich alles in einer Subdomain abspielt + Möglichkeit A für jede Subdomain. Also der speichert sozusagen auch noch mit woher das Cookie kam... Danke für deine Antworten! mit den RFCs bin ich schon weitergekommen, ich habe es jetzt einfach so gelöst, dass ich das Problem vermeide indem die Cookies auf dem Entwickelungsserver einfach einen anderen Namen bekommen.
Johannes O. schrieb: > Jasch schrieb: [snip] > Jasch schrieb: >> Sowas ist prinzipiell böse... > > Weshalb? Was ist daran schlecht? Wie gesagt: Die Domain (inkl. > Subdomain) gehören uns, da hat kein anderer Zugriff drauf, > sicherheitstechnisch also unbedenklich. Und dazu haben die Cookiedaten > selbst keine wertvollen/geheime Informationen. Du hast doch die Probleme beschrieben die Du damit hast... ;-) Konservativ sein zahlt sich meistens aus. Gibt sogar eine Internet-Regel dazu: "Be conservative in what you send; be liberal in what you accept", sprich Postels Law. Aus Sicherheitsgründen ist jeder Austausch von Daten zwischen verschiedenen Servern über vom Angreifer manipulierbare Wege (in diesem Fall: Cookies, übrigens auch DNS - aber das ist ja überall irgendwie beteiligt) keine gute Idee. Bloss weil uns jetzt gerade kein Angriffsszenario einfällt heisst nicht das die Angreifer nicht schlauer sind als wir. Dass da bloss irgendeine ID drinsteht ist keine Ausrede, irgendjemand wird einen Weg finden auch damit Unfug anzustellen. Ist noch nicht so lange her dass SQL Injection kein Begriff war... Wenn Du Dinge zwischen den verschiedenen Servern "bereden" willst nimmst Du dafür besser ein internes Netz zwischen denen. > Jasch schrieb: [snip] > RFC sagt: >> If the user agent receives a new cookie with the same cookie-name, >> domain-value, and path-value as a cookie that it has already stored, >> the existing cookie is evicted and replaced with the new cookie. > > => Die beiden Cookies sind die gleichen. Sie haben den gleichen Namen > "visitor", die gleichen Pfad "/" und die gleiche Domain .asdf.de Ooh, ich hatte das so verstanden dass Du einmal dev.asdf.de und dann .asdf.de hast. [snip] >> Merke: ein Cookie ist definiert durch "cookie-name, domain-value, and >> path-value". Zwei Cookies mit domain-value ".foo.de" und "bar.foo.de" >> sind verschieden und werden beide an "bar.foo.de" gesendet! >> >> Keine Wildcards benutzen macht die Sache viel einfacher. > > Habs oben schonmal geschrieben, aber genau das ist ja mein Problem: Die > beiden Cookies sind wirklich exakt gleich. Darum ist es merkwürdig warum > da ein Unterschied gemacht wird. Hmm, sieht aus als ob Firefox da ein Problem hat. Wenn die Domains, der Pfad und der Name genau gleich sind und die RFC keine Sonderbehandlung für Wildcards definiert (hab ich jetzt nicht nachgelesen) müsste der Cookie eigentlich ersetzt werden.
Danke auch nochmal für deine Antwort! Werd mich mal umsehen nach nem Art "Firefox Supportforum" und dort nachfragen ob es sich um einen Bug handelt. Einen Bug zu melden erscheint mir gerade noch zu früh. Nochmal zur Wildcard bzw. Datenaustausch zwischen Subdomains: Es soll nur zwischen www.asdf.de und login.asdf.de der Cookie übertragen werden bzw. bestehen bleiben. Das ist der gleiche Server und sogar der gleiche Ordner darauf, das Script erkennt die Subdomain und gibt den passenden Content aus. Könnte man natürlich auch mit Unterordern machen wie z.B. www.asdf.de/ und www.asdf.de/login/, ist aber von den URLs her nicht so schön (sag nicht ich sondern andere Leute im Team) Daher sollte sich da kein Problem ergeben. Die Benutzer werden auch nie dev.asdf.de zu Gesicht bekommen, das ist ein Passwortgeschützter Entwicklerbereich. Das ist dann wirklich ein anderer Server!
Johannes O. schrieb: > Werd mich mal umsehen nach nem Art "Firefox Supportforum" Da gibts z.B. die Mailing-Listen: * https://lists.mozilla.org/listinfo/support-firefox <- Hilfe * https://lists.mozilla.org/listinfo/dev-apps-firefox <-Entwickler
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.