Win a copy of Java Mock Exams (software) this week in the Programmer Certification (OCPJP) forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Session expires on redirect unless you've already visited another site on the same domain?

 
Alex Lieb
Ranch Hand
Posts: 60
3
Java Netbeans IDE Notepad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.

I'm trying to deploy a new version of our work site thing on our test site, and I'm running into a bug that I have no idea how to account for.

Everything is working locally, so I deployed the project to our test site. I was able to log in  to the project just fine, and submit some forms, but the moment I followed any navigation path that didn't include a form submission, it would lose track of the session. Requests that included the session ID in the queryString were also able to go through just fine, but if you were to click on a link which had an href of, say, "gotoCheesecakeCenter.do", it would tell you your session was expired and kick you out.

So... I tried logging into the old version of the same project, which has been and is currently hosted on the same server, to see if that was happening there too. It was not. So I went back to the new version again and suddenly everything was working and it stopped losing track of the session. I had also changed a setting in some other random place while I was checking the old version to see if it had the bug too, so I figured whatever setting I'd changed had fixed it.

Then later on in the day, I rebooted the server and tried to log back into the new version of the site, and it did the exact same thing... Curious, I logged in to the old version, then closed the tab and logged back in to the new version, and once again, it stopped forgetting who I was. I would love to throw every config file in my project at you guys, because I'm aware that just a bland description of the issue isn't

There is something weird going on here. Somehow these two projects are still linked in the mind of the machine, and I'm not sure how or why. We're demo'ing this on Thursday, so I'd like to iron out most of the major bugs before then, but I do have a workaround that'll work for the moment. So it's not urgent, but if anyone knows why this might be happening or what I can do to fix the new version of the site so it works the same way the old one does, or if anyone knows why logging in to the *old* site would have any impact on the *new* site's ability to keep track of my session ID, that would be awesome.
 
Joe Ess
Bartender
Posts: 9370
11
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is odd.  The only thing I can think of is that your new application isn't really creating a session or has an absurdly short session timeout.  Try adding an HttpSessionListener (perhaps also HttpSessionAttributeListener for more granularity) to both applications and see what the life cycle of your sessions are. 
 
Alex Lieb
Ranch Hand
Posts: 60
3
Java Netbeans IDE Notepad
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think we figured it out in a manner of sorts...

Our apache server or our ssl config or some weird magic internet machine working in the background; I forget which thing it is, is set up to invalidate sessions if they make certain types of requests over http instead of https? And the reason this issue shows up on test but not production is we still allow http requests on test. If you try to make an http request on production, it'll send you instead to wherever you were going, but over https. It doesn't *let* you use http. On our test site though, it does *let* you use http... Like, you're totally allowed, we're just, you know, going to invalidate your session every time you try to make a request that doesn't explicitly carry along the session ID in the request. Or something.

As you may have gathered by now, I am incredibly sketchy on the details. Partially because we fixed it yesterday and I forgot I asked this question on here until just now, and partially because although I did set up the apache server and tell it how to play nice with Tomcat on this particular domain I'm generally still kind of a noob in the world of port forwarding/SSL config/secure connection handling and all that jazz. I am not yet server-fu enough for that plane of enlightenment. The point is this won't impact how the site runs when we do push it to the production environment, and for the test environment we just have to remember to make sure our requests start with https://
 
Happiness is not a goal ... it's a by-product of a life well lived - Eleanor Roosevelt. Tiny ad:
the new thread boost feature: great for the advertiser and smooth for the coderanch user
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!