Thomas > -----Original Message----- > From: Olaf Kock [mailto:tom...@olafkock.de] > Sent: Monday, January 11, 2016 4:12 PM > To: Tomcat Users List > Subject: Re: Tomcat 8.0.30 Session lost > > Well, at least you do a bit of protection instead of just disabling the > session fixation security filter. However, be aware that potentially many > people might come from the same IP address - either because it's a NATing > home router or a big company's proxy server. Especially if you want to attack > someone who's in the same network as yourself, this IP-based protection is > quite useless. > > I think I'm seeing the problems, and as long as you know what you're doing > and you accept the unavoidable consequences of this lower grade protection, > everything is fine. > > It still sounds funny that the session is not available with the next > requests... Might be worth to try different browsers for their timing on the > receipt of the cookie
+1 Have you tried different browsers, say Internet Explorer, Chrome, and Firefox to see if the behavior is the same for all? This is kind of a long shot, but I'll mention it anyway. I had a similar kind of problem, where every resource request on a page was trying to create a new session. It turns out IE had a bug processing URL's with special chars in them, in my case an underscore "_". Using a different browser other than IE, or accessing the server by IP address instead of DNS name, hid the problem. After researching, experimentation, and pulling my hair out, I finally realized the underscore was the issue. Renaming the server solved the problem. Use keyword "weirdness" to search for old posts on this topic. Perhaps another long shot, and please forgive me if you have already made this clear, have you verified the timing and concurrency of your authentication and loading of page resources? IOW, are they the same, or different use-case events? > Also, as you call HttpServletRequest.login manually, double check that you're > doing this before the response is committed to the client, specifically > before any other (old) session id cookie is already in the response stream. > It sounds weird, but might help you debug further (note that I'm not looking > at tomcat's code. Apologies if I'm not making sense) > > Olaf > > Am 11.01.2016 um 21:52 schrieb Thomas Scheffler: > > > > I will file two bugs soon describing the issues I had. Hopefully they > > will be fixed. > > > > 1.) if using HttpServetRequest.login(String, String) further request > > in the session are loosing the users Principal. > > > > 2.) After changing sessionId, old sessionIds should still be valid for > > a short period of time of to the same client. > > > > Fixing one of these would cause the bug to disappear. > > > > To prevent session fixation attacks, I use IP address checking so that > > sessions are bound to the same IP address. > > > > Thanks to all the responses. Without you help it would have not been > > possible to get this fixed after two month of searching! > > > > kind regards, > > > > Thomas > > -- Cris Berneburg, Lead Software Engineer, CACI
