Deux clients (utilisant les deux Firefox 3.6.16 ; un sous Mac un sous Win) "perdent" leur session chez nous très régulièrement (au bout de quelques requêtes, à moins de quelques secondes du login). Jamais sur le même appel, cela semble relativement aléatoire.
Je cherche donc déjà à tracer tout les headers HTTP dans les deux sens pour voir si : - le cookie de session est toujours bien retourné par le client (et son contenu) - si on aurait pas mis du delete cookie dans une réponse par erreur En gros déjà isoler si c'est un problème coté client ou coté applicatif. On n'a pas la main sur les clients, c'est du genre client lambda. Pour la petite histoire du X-Forwarded-For, c'est pas toujours idéal parce qu'il est trafiqué à chaque étage des reverse-proxy et chacun rajoute sa merde (entre autre les proxys de sorties des grosses entreprises), notre frontal ajoute un X-Real-IP pour avoir simplement l'IP d'où vient la requête sans se prendre la tête. Le frontal est un nginx, je vais voir s'il est possible de lui faire dumper les headers dans les deux sens, mais je vais aussi regarder en prioriter le tcpdump en amont du SSL et décrypter le flux. Le 27/04/2011 12:04, Hervé COMMOWICK a écrit : > A grand coup de tshark, tu dois pouvoir filtrer ca correctement : > http://www.wireshark.org/docs/dfref/h/http.html > > Par contre il te faudra sans doute modifier le nom du header pour le > standard de facto X-Forwarded-For, car je ne vois pas comment le > spécifier autrement. > > C'est quoi le bug bien velu sinon ? > > Hervé. > > On Wed, 27 Apr 2011 11:37:53 +0200 > Valentin Surrel <valen...@surrel.org> wrote: > >> Bonjour la liste, >> >> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau >> entre un client et nous. Problème, on a un frontal qui fait du SSL et >> rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs >> d'application. >> >> Un moyen de trouver les requêtes que fait le client est de faire ça : >> >> ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 >> >> 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas >> tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y >> avoir d'option pour ceci dans ngrep. >> >> Auriez-vous des pistes à me suggérer (on peut très difficilement tout >> enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi >> impossible du fait de sa taille) ? >> >> Est-il possible de faire le tcpdump en amont du frontal sur l'IP >> 1.2.3.4 et ensuite de décoder le HTTPS ? (avec wireshark ?) >> >> Merci de votre aide ! >> >> Valentin >> _______________________________________________ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ > > > _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
