Firefox weigert sich einen Cookie zu löschen

**combie** · 25.11.2008, 08:48

1. Wenn du Cookies löschen willst, dann solltest du den Wert leer lassen.
2. 1 Stunde als negative Ablaufzeit ist arg wenig... Was ist, wenn der Server(oder Client) in Australien oder auf Tonga steht? Verwende besser eine Woche o.ä.
3. Warum löscht du das Cookie, wenn du doch 2 hundertstel Sekunden später wieder eins setzt? Das ist doch völliger Unsinn!!(du hast diesen Teil des HTTP nicht verstanden)

**mgutt** · 06.01.2009, 01:24

Ich habe witzigerweise genau das gleiche Problem. Das existiert nur bei FF3 und diversen IE Versionen. Und zwar nimmt der Browser einfach Cookies doppelt an.

Ich habe meine Mitglieder um einen Screenshot gebeten und später teilte mir ein weiteres Mitglied mit, dass die Cookies zu 100% identisch seien, nur eben das Ablaufdatum (gültig bis) sei unterschiedlich.

Nun habe ich meinen Code geprüft und kann einfach keinen Fehler finden. Der Fehler taucht ausschließlich bei den Nutzern auf, die per Autologin neu angemeldet werden sollten. Sobald der Inhalt des Cookies verifiziert wurde, aktualisiert mein Script das Datum des Autologin-Cookies, so dass es wieder ein Jahr lang gültig ist. Genau in diesem Moment aktualisiert der Browser aber nicht das Cookie, sondern nimmt einfach das gleiche Cookie noch mal an.

Das darf doch eigentlich gar nicht passieren oder? Ich mein die Cookies heißen gleich, haben die gleiche Domain, den gleichen Pfad und sind nicht an bestimmte HTTP-Verbindungen gebunden. Also warum nimmt der Browser dann einfach das Cookie nochmal an

Ich könnte mir vorstellen, dass ich den gleichen Fehler drin habe wie brabbelj und zwei mal das gleiche Cookie lösche und wieder setze. Nur im Moment finde ich noch nicht heraus wo das passiert.

Ist es aber nicht trotzdem ein Bug der Browser ein und das selbe Cookie noch mal anzunehmen?

**jmc** · 06.01.2009, 04:10

Ich kenne auch jmd. der das Problem einmal hatte. Es kam heraus, dass es eine Anpassung an Standards darstellt wobei das Cookie folgendermassen gelöscht werden sollte:

PHP-Code:


setcookie("dl_limit", false, -1, "/", $host, false);

Falls es so immer noch nicht gelöscht wird liegt es sehr wahrscheinlich an deiner Variabel $host.
Also schreib die dann doch bitte einfach auch mal noch ins Forum. Ein häufiger Fehler ist auch, dass man vergisst die Domain mit einem Punkt zu beginnen.

[EDIT]
Falls es nicht funktioniert nähme mich auch noch der Response-Header vom Server wunder.

**fireweasel** · 06.01.2009, 13:28

Original geschrieben von mgutt
Ist es aber nicht trotzdem ein Bug der Browser ein und das selbe Cookie noch mal anzunehmen?

Im Prinzip ja, aber ich gehe eher davon aus, dass die Browser das schon richtig handhaben.
Ergo muss es sich um zwei verschiedene Cookies handeln. Die Firefox-Cookie-Liste ist immer noch[1] eine simple Text-Datei mit dem bezeichnenden Namen "cookies.txt". Die kannst du dir mit einem Text-Editor deines Vertrauens mal ansehen, dann weißt du, wo die Unterschiede zwischen deinen beiden "identischen" Cookies liegen.

--
[1] Zumindest bis FF2. Aber ich gehe mal davon aus, dass die cookies.txt auch in der Dreier-Version noch existiert.

**Zipper5004** · 08.01.2009, 16:45

kann man die Zeit nicht einfach auf 0 setzen, und der Browser löscht die Cookies automatisch? da die ablaufzeit ja erreicht ist.

**combie** · 08.01.2009, 17:08

Automatisch?
Ja, wenn du den Browser schließt!

Session Cookies werden mit der Laufzeit 0 gesetzt.

**Zipper5004** · 09.01.2009, 11:36

dann wars mit minus, oder so, aber man kann irgendwie durch rutnersetzen der Zeit ein cookie löschen, zu mindest deaktivieren, dass der server es nicht mehr beachtet

**mgutt** · 27.02.2009, 15:05

Also ich habe jetzt mal folgendes gemacht:
Wenn ein User sich einloggt und der Login nicht in der Lage war das Cookie zu setzen / überschreiben, wird er auf eine Seite weitergeleitet, die Step-by-Step alle möglichen Varianten durchprobiert.

1. Versuch:

Code:

setcookie('phpbb2max_data', 'a:2:{s:6:"userid";i:-1;s:11:"autologinid";s:0:"";}', 
time() + 31536000, '/', $cookie_domain);
setcookie('phpbb2max_sid', $_COOKIE['phpbb2max_sid'], 0, '/', $cookie_domain);

2. Versuch:

Code:

setcookie('phpbb2max_data', '', time() - 31536000, '/', $cookie_domain);
setcookie('phpbb2max_sid', '', time() - 31536000, '/', $cookie_domain);

3. Versuch:

Code:

setcookie('phpbb2max_data', '', 0, '/', $cookie_domain);
setcookie('phpbb2max_sid', '', 0, '/', $cookie_domain);

4. Versuch:

Code:

setcookie('phpbb2max_data', '', -1, '/', $cookie_domain);
setcookie('phpbb2max_sid', '', -1, '/', $cookie_domain);

5. Versuch:

Code:

<script type="text/javascript">
function cC(n,v,d) {
	var t = new Date();
	if (!d) {
		t = new Date(t.getTime() - 1);
	}
	else {
		t = new Date(t.getTime()+(d*24*60*60*1000));
	}
	var data = n+"="+v+"; expires="+t.toGMTString();
	data = data + "; path=/ domain=<?= $cookie_domain ?>";
	document.cookie = data;
}
function cV() {
	cC('phpbb2max_data', '', '');
}
window.onload = cV;

Nach jedem Versuch muss der User eine Seite weiterklicken, damit das Ergebnis geprüft werden kann. Das Cookie "phpbb2max_sid" wurde beim 2. Versuch erfolgreich gelöscht. Das Cookie "phpbb2max_data" wurde mit keinem der Versuche gelöscht / geändert.

Ein User hat das Problem beispielsweise mit Opera 9.63.

Dieses Problem taucht vor allen Dingen bei Usern mit Opera 9 und Firefox 3 auf (ca. 1% aller Nutzer). Ich schätze, dass bei einem Update des jeweiligen Browsers die Schreibrechte für die Cookies verloren gegangen sind und der Browser nicht mehr in der Lage ist das alte Cookie zu entfernen.

Hat noch jemand eine Idee? Meine Idee wäre es den Cookienamen in dem Fall zu ändern (wenn das Cookie nicht gesetzt werden konnte), also abhängig von der Browserversion zu benennen. Dann würden die Autologins zwar bei einem Browserupdate verloren gehen, aber das ist immer noch besser als einen Besucher zu verlieren, der nicht weiß, wie man seine Cookies löscht.

Ich dachte z.B. daran:

PHP-Code:


$cookie_name = md5(SALT. $_SERVER['HTTP_USER_AGENT']);

statt:

PHP-Code:


$cookie_name = 'phpbb2max_data';

Das Problem mit den doppelt gesetzten Cookies konnte ich noch nicht lösen, habe aber die Vermutung, dass es sich dabei um das gleiche Problem handelt. Das würde auch meine Vermutung, dass es sich um einen Browserbug handelt, bestätigen.

Gruß

**wahsaga** · 27.02.2009, 15:21

Original geschrieben von combie
1 Stunde als negative Ablaufzeit ist arg wenig... Was ist, wenn der Server(oder Client) in Australien oder auf Tonga steht?

Auch da ist der Unix Timestamp immer gleich ...

Original geschrieben von mgutt
[...] aber das ist immer noch besser als einen Besucher zu verlieren, der nicht weiß, wie man seine Cookies löscht.

Das koennte man ihm vielleicht erklaeren, auf einer Extra-Seite "Was kann ich tun, wenn ich mit dem Login Probleme habe?" - halte ich fuer sinnvoller, als irgendwelche kruden Workarounds zu implementieren, die fuer den allergroessten Teil der Nutzer nicht notwendig sind, und weiteren Aufwand im scriptseitigen Handling verursachen.

**combie** · 27.02.2009, 15:37

PHP-Code:


$cookie_domain = md5(SALT. $_SERVER['HTTP_USER_AGENT']);

Ist völliger Unsinn, da kommt niemals eine gültige Domainmaske bei rum.

Auch da ist der Unix Timestamp immer gleich ...

Nicht jeder Server(aber die meisten) sendet im Response einen Timestamp mit. Leider!
Der Browser ist gehalten, sich an dem gesendeten Timestamp zu orientieren. Gibts keinen, verwendet er seine Systemzeit. Setzt man die Ablaufzeit etwas großzügiger, gibts seltener Sorgen.

In phpbb2max_data befinden sich offensichtlich serialisierte Daten. Das ist nicht sehr klug: [google]php unserialize Buffer overflow[/google]. Eine vermeidbare Angriffsfläche.

time() - 31536000

Finde ich unschön!

Vorschlag:
Setzen eines Cookies:

PHP-Code:


setcookie('name','daten',strtotime('+5 week'),'/','.example.com');

Löschen des Cookies:

PHP-Code:


setcookie('name','',strtotime('-1 year'),'/','.example.com');

**mgutt** · 27.02.2009, 17:05

Original geschrieben von combie
[B]

PHP-Code:


$cookie_domain = md5(SALT. $_SERVER['HTTP_USER_AGENT']);

Ist völliger Unsinn, da kommt niemals eine gültige Domainmaske bei rum.

Stimmt. Ist ein Schreibfehler. Ich meinte den $cookie_name natürlich, sorry!

Also statt:

PHP-Code:


$cookie_name = 'phpbb2max_data';

das:

PHP-Code:


$cookie_name = md5(SALT. $_SERVER['HTTP_USER_AGENT']);

Kritik dazu ist erwünscht.

In phpbb2max_data befinden sich offensichtlich serialisierte Daten. Das ist nicht sehr klug: [google]php unserialize Buffer overflow[/google]. Eine vermeidbare Angriffsfläche.

Unsinn, weil diese Sicherheitslücke bereits lange in PHP geschlossen wurde (war mal in 4.3).

Finde ich unschön!

PHP-Code:


strtotime('-1 year')

Aus Performance-Sicht macht der Einsatz von strtotime() an dieser Stelle keinen Sinn. Auch wenn der Negativ-Effekt nur maginal ist, reines Subtrahieren ist einfach schneller.

**combie** · 27.02.2009, 17:25

Unsinn, weil diese Sicherheitslücke bereits lange in PHP geschlossen wurde (war mal in 4.3).

Und ist irgendwo in den 5.1.X Versionen wieder aufgetreten. Und davon sind noch ettliche draussen tätig. Auch gabs in den 5.2.x noch Memoryleaks, und andere seltsamme Erscheinungen, z.B. mit 32 vs. 64 Bit Daten.

Mein Tipp:
Niemals serialisierte Daten vom Browser akzeptieren.

**mgutt** · 27.02.2009, 17:35

Original geschrieben von combie Und ist irgendwo in den 5.1.X Versionen wieder aufgetreten. Und davon sind noch ettliche draussen tätig. Auch gabs in den 5.2.x noch Memoryleaks, und andere seltsamme Erscheinungen, z.B. mit 32 vs. 64 Bit Daten.

Mein Tipp:
Niemals serialisierte Daten vom Browser akzeptieren.

Hmm. Gut dann baue ich mir dazu mal ein eigenes Konzept. Sollte jetzt aber nicht grundsätzlich Thema dieser Diskussion sein, auch wenn ich für den Tipp dankbar bin.

Original geschrieben von wahsaga Das koennte man ihm vielleicht erklaeren, auf einer Extra-Seite "Was kann ich tun, wenn ich mit dem Login Probleme habe?" - halte ich fuer sinnvoller, als irgendwelche kruden Workarounds zu implementieren, die fuer den allergroessten Teil der Nutzer nicht notwendig sind, und weiteren Aufwand im scriptseitigen Handling verursachen.

Damit bist Du gezwungen für jeden Browser eine eigene Erklärung zur Verfügung zu stellen und das bei Nutzern, die nicht mal die Bedeutung des Wortes "Cookie" kennen

Weiterhin hast Du das Problem, dass IE-Nutzer in aller Regel alle Cookies löschen müssen. Das wäre aus Nutzersicht nicht akzeptabel. Mit Komfort hat sowas auch nichts zu tun. Ich sehe es trotz des Browser-Bugs eher als meine Aufgabe, dafür eine Lösung zu finden.

Es ist sogesehen kein Problem den User-Agent in den Cookienamen einzubeziehen. Aktuell sehe ich jedenfalls keinen Nachteil dabei, außer das bei einem Update der Autologin weg ist. Aber ich denke das ist eher zu verkraften, als dem Nutzer die Aufgabe aufzuerlegen.

EDIT:

Original geschrieben von combie
Und ist irgendwo in den 5.1.X Versionen wieder aufgetreten. Und davon sind noch ettliche draussen tätig. Auch gabs in den 5.2.x noch Memoryleaks, und andere seltsamme Erscheinungen, z.B. mit 32 vs. 64 Bit Daten.

Mein Tipp:
Niemals serialisierte Daten vom Browser akzeptieren.

Noch mal danke für den Hinweis. Ich schreibe nach wie vor die Daten mit serialize() aber ich verzichte auf den Einsatz von unserialize(). Da ich sowieso ein preg_match() auf den Hash anwenden musste, habe ich einfach einen vollständigen preg_match() auf den gesamten Cookieinhalt umgesetzt:

PHP-Code:


if (isset($_COOKIE['phpbb2max_data'])

 && ($_COOKIE['phpbb2max_data'] = stripslashes($_COOKIE['phpbb2max_data']))

 // hier im forum ist ein fehler wg. smilies, daher die trennung

 && $_COOKIE['phpbb2max_data'] != ('a:2:' . '{s:6:"userid";i:-1;s:11:"autologinid";s:0:"";}')

 && preg_match('#^a:2:\{s:6:"userid";i:' . '([0-9]{1,8});s:11:"autologinid";s:32:"([a-f0-9]{32})";\}$#',

 $_COOKIE['phpbb2max_data'], $matches)) {

    $sessiondata = array(

        'userid' => intval($matches[1]),

        'autologinid' => $matches[2],

    );

}

else {

    $sessiondata = array(

        'userid' => ANONYMOUS,

        'autologinid' => '',

    );

}

Firefox weigert sich einen Cookie zu löschen