2009-07-17 7 views
43

J'ai trouvé un étrange problème de cookie sur Safari. Si vous surfez sur http://2much.ch vous pouvez entrer avec FF/IE et surfer sur le site. Mais si vous utilisez safari, vous ne pouvez entrer qu'une seule fois; vous ne pouvez pas surfer sur le site. J'ai trouvé que Safari ne définit pas le cookie entré, mais FF/IE le fait.Safari ne définit pas Cookie mais IE/FF fait

Quel est le problème ici?

+2

Je n'ai rien à ajouter sauf: le meilleur nom de domaine. –

+0

hehe, thx :) Peut-être que je le vends :) – Gomez

+0

Peut-être que vous pouvez expliquer un peu à propos de la partie de réglage des cookies. Par exemple: est-ce fait par un add-on Plone ou un code personnalisé? –

Répondre

62

Il semble que vous ayez rencontré un bug Safari ici; vous redirigez un navigateur visite à/entrée lors de la configuration du cookie en même temps, et Safari ignore l'en-tête Set-Cookie lors de la rencontre de l'état 302 HTTP:

$ curl -so /dev/null -D - http://4much.schnickschnack.info/ 
HTTP/1.1 302 Moved Temporarily 
Server: nginx/0.7.61 
Date: Sun, 19 Jul 2009 12:20:49 GMT 
Content-Type: text/html;charset=utf-8 
Connection: keep-alive 
Content-Length: 14260 
Content-Language: de 
Expires: Sat, 1 Jan 2000 00:00:00 GMT 
Location: http://4much.schnickschnack.info/entry 
Set-Cookie: colorstyle="bright"; Path=/; Expires=1248092449.12 
Set-Cookie: _ZopeId="73230900A39w5NG7q4g"; Path=/ 

Techniquement, ce serait un bogue dans Apple Classes de fondation, j'ai trouvé un WebKit bug qui indique que c'est le cas.

Je suppose que la solution de contournement consiste à définir le cookie non pas dans index_html mais dans l'entrée à la place.

+2

Merci pour la bonne explication, Martjin! J'ai mis le code dans l'entrée /. Maintenant ça marche. THX! – Gomez

+0

vous êtes un sauveur! – Paul

6

Il y a un mois, j'ai rencontré ce problème. Au début, je pensais que c'était un pot de biscuits corrompu car je pouvais nettoyer les cookies et partir.

Cependant, il est ressorti à nouveau. Cette fois, j'ai passé une heure à le parcourir, à regarder ce qui a été envoyé, à revoir ce que le safari a renvoyé, et j'ai trouvé le problème.

Dans ce cas, un tableau de valeurs de cookies a été envoyé au navigateur après la connexion avant la redirection. Les valeurs avaient l'air quelque chose comme « id utilisateur », « nom complet de l'utilisateur », « autre id », etc.

(oui, les id sont cryptés donc pas de soucis là-bas)

Mon nom d'utilisateur complet était en fait dans un format <lastname>, <firstname>.

Lorsque Safari renvoyait le cookie au serveur, tout ce qui se trouvait après la virgule après le nom de famille était supprimé. Il affichait seulement des valeurs de retour jusqu'à ce point. Lorsque j'ai supprimé la virgule, le reste des valeurs a commencé à fonctionner correctement. Il semble donc que si vous envoyez une valeur de cookie contenant une virgule, Safari n'échappe pas correctement à son stockage interne. Ce qui m'amène à penser que s'ils n'échappent pas correctement aux virgules, il y a probablement des problèmes de sécurité avec le code de gestion des cookies de safari. Par ailleurs, cela a été testé sur Win 7 x64 avec Safari 4.0.5. Aussi j'ai mis en place une page Web à: http://cookietest.livelyconsulting.com/ qui montre exactement ce problème. (J'ai supprimé ce site de test)

IE, FF et chrome définissent tous correctement le cookie. safari ne fait pas.

+4

Chris: votre problème est complètement lié à l'analyseur. Cela a à voir avec la façon dont CFNetwork fusionne les en-têtes Set-Cookie dans un en-tête Set-Cookie au cours de l'analyse HTTP. Généralement, les en-têtes HTTP dupliqués peuvent être fusionnés en un en-tête à l'aide d'un délimiteur ','. Malheureusement, Set-Cookies a été un en-tête historiquement cassé. Cela a été discuté lors d'une récente réunion de l'IETF. Il n'y a pas de problème avec la représentation interne des cookies. –

+2

@Mark Pauley: Heureux de voir une pomme parler activement de la façon dont safari gère les cookies. J'ai parcouru une partie de votre correspondance à http://www.ietf.org/mail-archive/web/http-state/current/msg00645.html Je pense que le fait que safari soit le seul navigateur à présenter ce comportement de rupture est une raison suffisante tirer la fonctionnalité. – NotMe

+3

Je ne sais pas pourquoi quelqu'un aurait voté contre cela il y a près d'un an; Cependant, le comportement est toujours cassé dans Safari 5.0.3. – NotMe

2

J'ai rencontré le même problème avec Chrome. Chrome n'ignore pas l'en-tête set-cookie pendant la redirection, mais vous ne connaissez jamais la commande (définissez d'abord le cookie ou la redirection). Voici quelque chose que j'ai essayé:

J'ai un site Web, qui prend en charge l'anglais et le français.Je l'ai implémenté (avec php) de cette façon:

localhost a un lien vers localhost/fr (qui set-cookie vers le français et redirige vers localhost). Ça marche. (mettre le cookie en premier)

localhost/path1 a un lien vers localhost/fr? return =/path1 (qui set-cookie en français et redirige vers localhost/path1). Ça ne marche pas. (rediriger en premier, la langue n'a pas changé)

localhost/chemin1 a un lien vers localhost/fr? return = www.google.com (qui set-cookie en français et redirige vers google). Quand je suis revenu sur mon site, c'est en français. (ce qui signifie set-cookie au français n'est pas ignoré, seulement exécuté après la redirection)

Espérons que je sois clair, l'anglais est une langue étrangère pour moi.

3

Nous avons rencontré un problème très similaire où Safari (version 7.0.6) ignorait un cookie. L'en-tête de cookie a semblé parfaitement bien, presque identique à un autre biscuit qui a été rappelé.

Il s'est avéré que le coupable était le précédent en-tête de cookie ayant une valeur expires malformée. La gestion par Safari des en-têtes de cookie cassés n'est évidemment pas aussi robuste que celle des autres navigateurs.

+0

Qu'est-ce qui a été malformé à propos de la valeur d'expiration? –

+1

@JohnBachir Désolé, je ne m'en souviens plus. Probablement, le format de date était invalide. –

Questions connexes