There is a Java webapplication deployed in tomcat and Apache webserver.
There is only one tomcat instance in production and there is no concept of loadbalancer.
But, after introducing Apache webserver, User A is able to completely see User B s data, meaning, User B's session is accessed by User A.
The same code was working fine, when there was only tomcat instance, now on introducing Apache web server, we are facing this session data crossover issue.
//httpd.conf properties
worker.list=tomcat_lb,jkstatus
# Define a 'jkstatus' worker using status
worker.jkstatus.type=status
worker.tomcat_lb.type=lb
worker.tomcat_lb.balance_workers=tomcat_1
#worker.tomcat_lb.balance_workers=tomcat_1,tomcat_2
# Specifies whether requests with SESSION ID's
# should be routed back to the same #Tomcat worker.
worker.tomcat_lb.sticky_session=True
Related
I am trying to implement a sticky session based load balancing across two Tomcat instances using the Hazelcast Tomcat Web Session Replication. For testing purposes, I have deployed the application on two different Tomcat instances and the load balancing is handled through Apache HTTPD. The jvmroute parameters and the mod-proxy settings are fine and the load balancing has no issues.
The problem is with the session replication across the two instances. When the first server (currently serving the request) goes down the request is sent to the second server. The Hazelcast cluster identifies that the session is through fail-over and is copying the session with the new session id (suffixed with the jvmroute parameter of the second server) - as described in the Hazelcast documentation https://github.com/hazelcast/hazelcast-tomcat-sessionmanager#sticky-sessions-and-tomcat) . However for the failed-over request, the session attributes are getting updated in the older session(failed over jvmroute) and not getting replicated resulting in the failure of the subsequent request.
I have gone through the documentation but unable to find a resolution at this point. I am sure I am missing some setting as this would be a basic setting for a fail over scenario.
Can someone help me out? Please let me know if you need any additional details.
[UPDATE]
After tracing the flow, able to determine that the handleTomcatSessionChange in com.hazelcast.session.HazelcastSessionChangeValve is being called correctly. The request.changeSessionId(newSessionId) call happens and post this if I display the value of the requestedsession id, the value is updated. However, the session id by itself is not updated and this is resulting in the older id in a request.getSession().getId() call.
I have a web application where I want to track which language a user wants to use to view the various pages. I am using a session attribute to store their selection. I set the session attribute like so...
String languageChosen = request.getParameter("LANG");
request.getSession().setAttribute("LANG", languageChosen);
Then in other methods I retrieve the attribute like so...
String languageChosen= (String) request.getSession().getAttribute("LANG");
When I test this application in my local environment - which is running Tomcat - it works perfectly. But when I deploy the application to our remote development server - which is Weblogic - the session attribute is not being captured. As a result the application is not displaying in the right language.
Should I be storing the session attribute differently for Weblogic? I've never run into this issue before. We have other apps running on the same Weblogic instance that utilize session attributes without issue. Any ideas?
I figured out the problem. The current development URL is not a secure URL and I had the secure cookie setting set to TRUE in my weblogic.xml file. Once I changed it to FALSE everything worked.
Now I just have to remember to change it back to TRUE when we move to a secure environment. Ha ha!!
We have a task to certify our application in Tomcat7 which is already certified and running in Websphere.
Our application in websphere has JAAS custom login module and it access HttpServletRequest object via callback handlers as shown below and we set user related information in the session object (which is retrieved from request).
javax.security.auth.callback.Callback callbacks[] = new javax.security.auth.callback.Callback[3];
callbacks[0] = new javax.security.auth.callback.NameCallback(
"Username: ");
callbacks[1] = new javax.security.auth.callback.PasswordCallback(
"Password: ", false);
callbacks[2] = new com.ibm.wsspi.security.auth.callback.WSServletRequestCallback(
"HttpServletRequest: ");
The problem here is that, as you see, the above code is specific to websphere. So, we want to write another custom login module specific to Tomcat. Excuse me, this is designed by someone else.
Now the queustion is how can I access HttpServletRequest/HttpSession object in Jaas login module in Tomcat?
Note: I have tried to use ThreadLocal to pass the user information instead HttpServeletRequest but it appears that it is not advised since threads are reused from Thread Pool in Tomcat and there could be a potential problems (memory leak, user information shared etc) in case if we don't clear the ThreadLocal properly.
In Jboss, it can be get through:
HttpServletRequest request = (HttpServletRequest) PolicyContext
.getContext("javax.servlet.http.HttpServletRequest");
But PolicyContext is in JACC and Tomcat does not support JACC yet. It might be supported in Tomcat 9, but low on Tomcat's priority.
You should not have to obtain the HttpServletRequest in the LoginModule. The LoginModule is the JAAS version of an identity store, which is a database/repository for users, their credentials and optionally groups or roles.
In Tomcat a LoginModule is not the prime identity store type. A Realm is, but Tomcat provides a bridge so you can use a LoginModule anyway. But as you have discovered the usage of JAAS in Java EE is not standard. Servers either don't use JAAS at all, or they use it differently from any other server.
What you're looking for is the authentication mechanism, which is the thing responsible for interacting with the request, response and session. Tomcat has two interfaces for that, one is Tomcat specific, the other is a Java EE standard.
The Authenticator see https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/authenticator/package-summary.html
The ServerAuthModule see https://tomcat.apache.org/tomcat-9.0-doc/config/jaspic.html and http://docs.oracle.com/javaee/7/api/javax/security/auth/message/module/ServerAuthModule.html
I'm trying to have my JSESSIONID at ".mysite.com" so it can be shared across subdomains.
I have a 4.2.2 GA JBOSS instance doing this with this method: http://shchekoldin.com/2010/05/27/sharing-jsessionid-across-subdomains/ (which is from here: https://jira.jboss.org/browse/JBWEB-107) using the custom valve approach.
However on the EAP 5.1 version (I've compiled against JDK 1.6) the same custom valve doesn't kick in. I added some debugging but it never gets called.
Also, I tried turning on the SSO option in server.xml (as per https://community.jboss.org/wiki/JBossWebSingleSignOn) through the non-clustered method, but this plays no impact on it either.
Does anyone know how I can the JSESSIONID cookie to sit across subdomains on JBOSS 5?
(Side note, if I have "foo.bar.mysite.com" will this ".mysite.com" domain stored against the cookie work for multiple sub domains - this is for testing, in prod we just have the one level).
I also had same requirement. Share session across sites having sub-domain and parent domain within same .war file. e.g www.baseball.sports.com and www.hockey.sports.com.
To share JSESSION b/w these two sites need to add domain tag in jboss-web.xml.
File path : /app/jboss/jboss-eap-6.1/standalone/deployments/mason_production/.ear/.war/WEB-INF.
Add below entries :
.sports.com
I found what I needed:
You add <SessionCookie domain="example.com"/> under in the WEB-INF/context.xml of your application.
All
I am developing an web application using Tomcat 6.X and My Eclipse.
When i do some changes in existing java files (Java Class, SERVLETS , Filter) , i have to redeploy it to the tomcat server . but, when i redeploy the application the
existing session becomes null .
is there any way that i can persist the existing session between re deployments from the MY ECLISPE.
From Tomcat Docs
Check here for tutorial on JDBC persistence , tomcat-6-session-persistence-through-jdbcstore
FileBased
JDBC Based Store
Restart Persistence
Whenver Catalina is shut down normally and restarted, or when an
application reload is triggered, the
standard Manager implementation will
attempt to serialize all currently
active sessions to a disk file located
via the pathname attribute. All such
saved sessions will then be
deserialized and activated (assuming
they have not expired in the mean
time) when the application reload is
completed.
In order to successfully restore the state of session attributes, all
such attributes MUST implement the
java.io.Serializable interface. You
MAY cause the Manager to enforce this
restriction by including the
element in your web
application deployment descriptor
(/WEB-INF/web.xml).