Les Cookies de Session et IE 8

J'ai récemment construit une simple application web déployée sur Tomcat. L'application utilise assez standard basée sur la session de la sécurité, où un utilisateur qui s'est connecté en est donné à une session.

Sessions fonctionnent très bien sous Firefox et Chrome, mais nécessitent l'utilisation de jsessionid dans l'URL pour IE (testé 7 & 8), défini sur moyen de confidentialité. Dans IE 8, j'ai essayé de remplacer la gestion des cookies, paramètre "Permettre à tous les 3rd party cookies" et "accepter les cookies de session"- pas de dés. Cependant, lorsque je lance Tomcat sur ma machine locale, c'est à dire accepte les cookies et les sessions fonctionnent tout aussi bien.

Et maintenant, pour les en-têtes HTTP.

À partir de Chrome, un utilisateur connecté a une séance

GET http://devl:8080/testing/HTTP/1.1
Host: devl:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1036 Safari/532.5
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
P3P: CP="NON CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT STA"
Set-Cookie: JSESSIONID=9280023BCE2046F32B13C89130CBC397; Path=/testing
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2450
Date: Fri, 26 Mar 2010 14:14:40 GMT

GET http://devl:8080/testing/logout HTTP/1.1
Host: devl:8080
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1036 Safari/532.5
Referer: http://devl:8080/testing/
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=9280023BCE2046F32B13C89130CBC397

...

De IE 8, avec une moyenne standard de niveau de sécurité et de confidentialité-

GET http://devl:8080/testing/HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; Tablet PC 2.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: devl:8080
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
P3P: CP="NON CURa ADMa DEVa TAIa OUR BUS IND UNI COM NAV INT STA"
Set-Cookie: JSESSIONID=192999F922D6E9C868314452726764BA; Path=/testing
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2450
Date: Fri, 26 Mar 2010 14:32:34 GMT

GET http://devl:8080/testing/logout HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Referer: http://devl:8080/testing/;jsessionid=6371A83EFE39A46997544F9146AA5CEA
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDC; Tablet PC 2.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: devl:8080

...

J'ai pensé qu'il pourrait être la norme P3P, mais sur l'ajout d'un pacte politique, rien ne change. C'est la norme Tomcat session, donc je suis vraiment surpris, je n'ai pas été en mesure de trouver d'autres personnes ayant le même problème jusqu'à présent. Quelqu'un a des idées?

MODIFIER 4/3/2010 -

Désolé si je n'ai pas fait ce clair - j'ai essayé à partir de plusieurs autres instances de l'IE - co-travailleurs en bas de la salle, etc.

MODIFIER 4/3/2010 -

J'ai aussi essayé de retourner sur invitation pour tous les cookies, mais je ne suis pas d'obtenir une invite de commandes. Réglage du domaine de la "Set-Cookie" en-tête à l'aide de Fiddler ne pas faire une différence, que ce soit.

Pourrait le cookie besoin d'avoir le domaine? Je ne sais pas un moyen de le configurer Tomcat, mais peut-être que je pourrais jouer avec les en-tête de cookie avec un filtre...
Pourquoi le referer dans votre dernier IE8 GET inclure le jsessionid dans l'url? Et quel outil utilisez-vous pour capturer le trafic ci-dessus (cuz un navigateur n'enverrait jamais GET http://...)?
Une autre chose que j'ai remarqué de la IE8 trace HTTP: la première requête tente de définir un id de session "Set-Cookie: JSESSIONID=192999F922D6E9C868314452726764BA; Path=/essais ", mais la deuxième demande a un autre id de session dans "Referer: ...;jsessionid=6371A83EFE39A46997544F9146AA5CEA". Étaient là interventions entre les 2 demandes? Est-il plus d'infos sur pourquoi il pourrait y avoir deux id de session? À tout hasard il y a plusieurs fenêtres concernés?
Je suppose que c'est la façon dont Tomcat gère les sessions lorsque les cookies sont désactivés; je ne fais rien bancale je ne pense pas que... - la seule fois que je créer une nouvelle session est lorsque le client n'en a pas.
Tomcat revient à accepter ";JSESSIONID=..." ajouté à l'URL de propager les informations de session lorsque les cookies sont désactivés. Ce n'est pas un peu bizarre IE caprice (bien qu'il ne risque pas d'arriver si IE accepté mes cookies)- lorsqu'un cookie de session n'est pas fourni, les pages JSP inclure l'id dans la suite des Url.

OriginalL'auteur Matt Luongo | 2010-03-26

  1. 9

    Je suis tombé sur ce problème précis, creusé autour pendant un moment, et trouvé ceci:

    http://forums.iis.net/p/1147938/1879164.aspx

    qui dit que les noms de domaine comportant des caractères de soulignement dans leur causer des problèmes avec Windows Server, tomcat et IE

    ne sais pas si cela résout votre problème (et à ce stade, vous n'avez probablement pas de soins), mais peut-être que la prochaine personne qui vient peut acquérir une certaine valeur.

    Wow - merci, cela a sauvé beaucoup de se tirer les cheveux (qui m'arrivait sur IE8).
    wow, je ne peux pas croire que c'était mon problème. Slow clap pour IE
    Jamais pensé à le trait de soulignement dans le nom de domaine peuvent causer ce problème. Nous devons changer tous notre nom de domaine maintenant.

    OriginalL'auteur johnbr

  2. 5

    Problème: IE8 a refusé d'accepter les cookies sur un site que j'ai construit, mais Firefox et IE7 a très bien fonctionné, et ce, pour les âges - c'était un code stable.

    Solution (pour moi): Mon serveur est dans un autre fuseau horaire de l'ordinateur client. Le STUPIDE, IDIOT IE8 essaie d'être intelligent et refuse d'accepter les cookies (stockées dans le local de la machine cliente) avec 20 minutes de vie. Mon code PHP a été directement depuis le livre de texte, donc:

    setcookie($name,$value,time()+1200);

    Mais il fonctionne très bien si je le change, par exemple -

    setcookie($name,$value,time()+120000);

    Cela me laisse encore avec le problème de l'cookie mourir au bout de 20 minutes, mais au moins mes utilisateurs peuvent maintenant utiliser mon site web avec IE8. Je passe sur cette information au cas où ça peut aider quelqu'un d'autre.

    J'ai vérification directe de ce que bien. Je lance un service d'analyse où le "infini" date d'expiration du cookie de bâtons, mais le +30 minutes de cookie de session est rejeté presque immédiatement. UA: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB0.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; PC Media Center 6.0; eSobiSubscriber 2.0.4.16; .NET4.0C)

    OriginalL'auteur Garth

  3. 1

    Avez-vous vérifié que le serveur de temps est-elle correcte?

    J'ai eu des problèmes similaires récemment avec IE n'accepte pas les cookies correctement. Après beaucoup de casse-tête, il s'est avéré être parce que la différence de temps entre le serveur et les ordinateurs clients était si grand que IE a refusé d'accepter le cookie. C'était dans Apache.

    Il n'y a qu'une minute de différence de temps, tops =/ Merci pour l'idée, que je vais garder qu'un planqué mon débogage de la manche.

    OriginalL'auteur Giles Smith

  4. 1

    Essayez d'utiliser le standard port HTTP (80). J'ai lu à propos de problèmes avec les numéros de port dans l'Url concernant la vie privée/sécurité dans IE plus d'une fois, mais n'arrive pas à trouver des liens pertinents à cette époque.

    J'ai aussi vu cela dans le passé. Si vous pouvez tester avec le port 80 pour voir si vous pouvez reproduire le problème.
    Merci pour l'idée, mais celui-ci ne fonctionne pas non plus. J'ai couru le site sur les deux 80 et 8080.

    OriginalL'auteur Josef Pfleger

  5. 1

    Je suis d'accord avec Lexicore - le cookie protocole du serveur web ressemble à droite, donc il y a quelque chose avec IE. Il serait plus facile de comprendre comment résoudre le problème si l'on comprend mieux pourquoi IE est en refusant les cookies. Sinon, demandez à un ami de frapper le site pour vous dans IE pour aider à confirmer son d'un problème de serveur pas un navigateur instance de problème.

    Voici quelques points à vérifier pour vous aider à déboguer avec IE et cookies - malheureusement, il y a un gâchis d'options à cocher. Désolé si certains de ces éléments semblent de base, je n'ai juste pas wnat faire de suppositions. Je suis en train de suivre dans IE 8.0 pour cela.

    Tout d'abord, accédez à l'emplacement de la cible (http://devl:8080/testing/) dans IE. Alors:

    1. Confirmer ce que la zone de IE classe 'http://devl:8080/testing/'. (Ce qui pourrait expliquer pourquoi sa fonctionne avec Tomcat sur votre machine locale.) La zone est affichée dans la barre inférieure du navigateur, et il est probable qu'il dit "Internet". Si au lieu dit "intranet Local", "Site de Confiance", ou "sites sensibles", ce peut être une partie du problème et que vous devez mettre à jour votre question ou à comprendre pourquoi il n'est pas classé comme Internet.

    2. Double-cliquez sur l'indicateur de la zone dans la barre du bas (sans doute "Internet") pour ouvrir la boîte de dialogue de Sécurité. Est le Niveau de Sécurité pour l'Internet, à Moyen-élevé? Si ce n'est pas le cas, cela pourrait être une partie du problème, et vous devriez probablement le réinitialiser à correspond à vos utilisateurs.

    3. Sélectionnez la zone "Internet" puis cliquez sur "personnaliser le niveau ..." pour ouvrir la boîte de dialogue Paramètres de Sécurité. Confirmer le "Userdata de la persistance" est réglé sur "Activer". Le "Userdata de la persistance de" l'option est dans le fond de 1/4 de la liste des options dans le "Miscenllaneous" (près de la partie inférieure de la section juste au-dessus de la section "Scripting").

    4. Cliquez sur OK dans chaque boîte de dialogue pour fermer les deux d'entre eux.

    5. Sur la barre de menu (activer si elle n'est pas activée), cliquez sur "Outils" > "Options Internet". Sélectionnez l'onglet "Confidentialité". Je sais que vous avez mentionné vous avez essayé des choses ici, mais ces changements peuvent ne pas affecter votre site si votre site n'est pas dans la zone Internet ou si votre site dans la rubrique "Actions de Confidentialité Par Site" liste d'exception, donc, de son mieux pour simplement confirmer.

    6. Est le paramètre de confidentialité dans l'onglet Confidentialité ensemble de Support? Si pas, vous pouvez réinitialiser les paramètres par défaut.

    7. Cliquez sur le bouton "site" pour ouvrir les Actions de Confidentialité Par Site dialogue. Est votre dev1 site classé? Si oui, retirez-la. Cliquez sur OK pour fermer la boîte de dialogue. Alternativement, vous pouvez forcer votre dev1 site pour toujours Autoriser les cookies.

    8. Cliquez sur le bouton "Avancé". Est "Ignorer la gestion automatique des cookies vérifié? Si oui, vous pouvez décocher pour correspondre à vos utilisateurs. Vous pouvez aussi essayer de les vérifier et en cochant la case "Toujours autoriser les cookies de session."

    9. Cliquez sur OK dans chaque boîte de dialogue pour fermer les deux d'entre eux.

    10. Confirmer le navigateur est toujours au site cible ('http://devl:8080/testing/'). Cliquez sur "Affichage" > Page de Politique de Confidentialité..." pour afficher le Rapport de Confidentialité boîte de dialogue. La liste inclut "http://dev1:8080/testing/"? Le Cookie colonne indiquent "Accepté" pour "http://dev1:8080/testing/"?

    11. Sélectionnez "http://dev1:8080/testing/" à partir de la liste. Cliquez sur le Résumé de voir la Politique de Confidentialité. Si en définir un pour votre site, vous devriez le voir ici. Sinon, vous devriez obtenir un message d'une politique de confidentialité n'a pas été trouvé. Regardez au bas de la boîte de dialogue pour voir comment le site est mis à utiliser des cookies (comparer, toujours autoriser, ou ne laissez jamais).

    Espère que cette aide ou vous donne quelques idées pour poursuivre.

    Ref:

    1. La zone est Internet. 2. Mis à moyen-élevé. 3. Permanence des données utilisateur est activé. 6. La vie privée est réglé sur moyen. 7. Mon domaine n'est pas dans la liste, il est vide. Je l'ai ajouté à la liste, en vertu de toujours autoriser - il ne fait pas de différence. 8. Comme je l'ai dit dans le post, ces options ne pas faire quelque chose pour moi. 10. L'url est inclus dans la liste, mais n'a pas le texte sous les cookies. Le haut de la boîte de dialogue de lecture en Fonction de vos paramètres de confidentialité, les cookies ne ont limité ou bloqué.
    11. Alors que mon URL n'est pas dans la liste, tous les enfants que j'ai visité ont été répertoriés. Résumé dit qu'aucune politique de confidentialité a été trouvé. J'ai défini l'action pour permettre, mais il ne fait aucune différence.
    Merci pour les idées, Bert. #11 semble bien que cela ait une certaine promesse, mais il me tue que je peux mettre toutes les options "autoriser" et cela ne fonctionne toujours pas.
    Bien, à moins que les règles de certaines choses. Veuillez noter mon nouveau commentaire à propos de plusieurs identifiants de session en vertu de la question d'origine.
    Je trouve bizarre que dans #10 les Cookies colonne est vide pour l'URL cible - sa capacité d'agir comme si IE ne pense pas que c'est d'avoir un quelconque Set-Cookie demande d'accepter ou de bloquer. Vous pouvez essayer cette expérience: dans Outils > vie privée > Avancé, activez l'option "Ignorer la gestion automatique des cookies", décochez la case "Toujours autoriser les cookies de session", et de définir des Cookies internes et Cookies Tierce partie à l'Invite de commandes. Ensuite, essayez de visiter le site à nouveau (même Url que vous traed) et de voir ce cookie IE8 pense de son obtention. Si vous n'obtenez jsessionid cookies, je me demande si ils sont toujours le même id de session ou si l'id de session changements.

    OriginalL'auteur Bert F

  6. 1

    Ce forum concernant P3P semble pertinent.

    Aussi avez-vous envisagé de mettre votre nom de domaine et la date d'expiration du cookie de session?

    OriginalL'auteur Jon D. Koon

  7. 0

    Cela a clairement rien à voir avec Tomcat, depuis le cookie est fixé - tout n'est pas acceptée par l'IE. Ce doit être le problème de sécurité dans IE puis.
    Peut-être ce MME article aiderait à régler.

    Euh, cet article est pour IE 5? La question pourrait avoir quelque chose à voir avec Tomcat, depuis Tomcat est le seul réglage, le cookie de session. Je ne peux pas le contrôle aléatoire des clients et de sécurité IE paramètres de confidentialité - je besoin de créer un cookie de session qui fonctionne avec le standard d'IE 7 & 8.

    OriginalL'auteur lexicore

  8. 0

    Zone de sécurité est le dev1 site? IE gère les cookies et beaucoup d'autres de la sécurité différemment en fonction de la zone (et de la façon dont la zone est configurée).

    Essayer de régler le dev1 site à explicitement partie des Sites de Confiance, par exemple, et voir ce qui se passe.

    Zones:

    Internet
Local Intranet
Trusted Sites
Restricted Sites

    Aussi, ne le cookie doivent être restreintes à l' /chemin de test? Essayez de /et voir si cela fait une différence.

    Généralement, le site dans la zone Internet. Ni les Sites de Confiance, ni Intranet Local modifie le comportement.
    pourquoi ne pas changer le chemin du cookie?

    OriginalL'auteur Goyuix

  9. 0

    Je voudrais essayer d'utiliser le nom d'hôte complet du serveur. MSIE traite de nom d'hôte sans domaines comme étant dans le "intranet Local" et s'occupe de la sécurité de manière différente.

    Plus précisément, au lieu de:

    http://devl:8080/testing/

    Essayez d'utiliser quelque chose comme:

    http://devl.mydomain.com:8080/testing/
    Ni est traité comme "intranet local"- je me suis demandé si j'aimerais intranet local option, et j'ai choisi aucun.
    Ainsi, lorsque vous passez le nom de domaine complet, est la seule différence que le "Host:" en-tête?

    OriginalL'auteur Jack Leow

  10. 0

    Il semble d'après ce que vous dites que vous n'avez vu que ce problème sous IE, et seulement en utilisant les ordinateurs de votre bureau. Est-il une sorte de "suite de sécurité" installé sur tous les ordinateurs de bureau, et si oui, pouvez-vous désactiver temporairement? Souvent, ces types d'applications crochet dans IE et de la boue avec sa pile HTTP. Si vous avez des logiciels tels que installé, vous avez une installation "propre" ou non de la société de l'ordinateur vous pouvez tester avec?

    OriginalL'auteur Jacob