I have been drafted to help move an application that was developed with a WebLogic server to Tomcat (not my idea). The application utilizes Struts 2 and Hibernate. It uses a login interceptor to get and save login information to the session. After moving the application from WebLogic to Tomcat, there is a problem with the session. Here is what is happening....
I have it set up to save login information to the session that is entered on the first screen. After I login and navigate to a new page, our application checks the session to see if login information is saved in it. When it does this, it should find the information that was saved in the login page but it does not, rather it finds the session null (I found this out by debugging) and returns me back to the login page. This means whenever I click on a link I get kicked back to the login screen since my user information is not accessible from the jsp page. It just keeps creating more and more sessions every time I log in without being able to access them from the jsp pages.
I have searched these forums and google for almost a month now to no avail. Again, this is working just fine on WebLogic. Thanks for any help!
Summary; Tomcat is not accessing already saved session.
One of the major reasons I continually rail against "Do It Yourself" security systems for J2EE apps is because you end up having to design and debug functionality that was already handled and debugged a decade ago. It's expensive. And, as a side note, I should point out that any security framework that requires the app to check to see if it's logged in is extremely like to develop security holes when maintainers come along and either don't know how to properly integrate into that process or overlook the task entirely.
Although the #1 reason I advise against DIY systems is that after all these many years, I still haven't found a DIY security system that wasn't insecure. Usually trivially so.
Nevertheless. The behaviour of HttpSessions is defined by the J2EE standard and both Tomcat and WebLogic provide exactly the same functionality. If you're seeing multiple sessions, it's far more likely to be a fault in your security system. There are 2 likely causes for multiple session generation:
1. You're meddling with the internals of the basic HTTP datastreams and damaging or losing the cookie that connects the client to a specific server session.
2. You've got cookies disabled and you're not providing the proper URL rewriting services that will allow the cookie ID to be transmitted as part of the URL, which is the only place that it can be tracked without cookies.
It is critical that you either employ cookies or properly-tagged URLS. HTTP does not keep continuously-open connections between client and server, so the only way to tell whether a client is continuing an existing conversation is to transfer a conversation identifier back and forth. That identifier is the sessionID.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.