Connexion HTTPS ne pas enregistrer le JSESSIONID dans un cookie

Question

Nous avons récemment modifié notre connexion pour utiliser HTTPS, et nous rencontrons des problèmes avec la connexion. Après la connexion, l'utilisateur est redirigé vers une page (HTTP) non cryptée. Quand il atteint cette page, le site vérifie si l'utilisateur est connecté. Il crée une nouvelle session et il apparaît que l'utilisateur n'est pas connecté, et donc notre utilisateur est redirigé vers la page de connexion. Si l'utilisateur se connecte à nouveau, cela fonctionnera.

Les cookies ne sont pas configurés uniquement en https, mais il semble qu'ils ne fonctionnent pas sur les pages http.

Est-ce que quelqu'un sait pourquoi cela pourrait se produire.

Edit:

Je aurais dû mentionner que la page qui affiche la connexion est sur une autre URL. (Il existe une page de connexion de la machine exécutant l'instance tomcat, mais le site marketing est installé sur WordPress et utilise un domaine différent).

Je ne peux pas utiliser la première méthode de demande HTTP pour définir le cookie, car les paramètres Internet Explorer par défaut empêchent l'enregistrement du cookie de session.

Answer 1

Lors de l'utilisation de https tomcat établit le jsessionid via un cookie sécurisé, qui ne peut pas être transmis via une connexion non sécurisée. Donc, quand vous retombez à http, la session est perdue. La solution de contournement (que je ne l'ai pas fait moi-même) semble établir la session par le biais d'une requête http avant de rediriger vers https, puis définir un filtre dans le HttpRequestWrapper pour se connecter au cookie non sécurisé.

Je ne sais pas grand-chose à ce sujet, mais voici quelques références:

• http://forums.sun.com/thread.jspa?threadID=197150
• http://tp.its.yale.edu/pipermail/cas/2006-March/002356.html

Answer 2

Nous avons ce problème avec notre application. Nous voulions un comportement similaire de connexion via https, puis rediriger vers une page http.

Le problème est que lorsque Tomcat crée la session sous https, il crée un cookie sécurisé qui ne peut pas être lu dans http. Notez que cela continue d'être classé comme un bug dans Tomcat et d'être marqué comme "pas un bug".

La solution nous avons fini est basé sur le message dans ce forum http://forum.java.sun.com/thread.jspa?threadID=197150&start=0

Je cite le fil du forum: « Une façon de maintenir la session dans Tomcat, lorsque le cookie de session est obtenir créé en mode SSL pour tromper le navigateur en créant le cookie non sécurisé, lorsque le cookie sécurisé est créé. " Ceci est accompli via un filtre qui enveloppe la requête et remplace request.getSession(). Cela a très bien fonctionné pour nous. En guise de remarque, la redirection d'une page https vers http fera apparaître un message d'avertissement dans certaines versions d'Internet Explorer "Vous êtes sur le point d'être redirigé vers une connexion qui n'est pas sécurisée." Le seul moyen que nous avons trouvé pour éviter cela est d'avoir la redirection effectuée avec une balise meta refresh. Spécifiquement, renvoyez une page vierge de la demande https d'origine avec une balise meta qui actualise à une page http. Cela évite le message d'avertissement au détriment de rendre le code légèrement plus compliqué.

(Je viens de remarquer certains des conseils ici est une répétition d'une réponse précédente - je m'excuse, mais posterai de toute façon, car il est de l'expérience directe).

Modifier: Je vois dans vos commentaires que vous avez deux domaines, ce qui complique l'utilisation des cookies. Pouvez-vous utiliser un proxy ou un serveur Web tel qu'Apache pour présenter un seul domaine aux utilisateurs finaux?

Answer 3

Si vous avez vérifié que l'indicateur de sécurité seule est désactivé et que le premier cookie a été supprimé correctement, j'imagine qu'il peut exister un problème de chemin qui empêche la présentation du cookie à nouveau.