WAS app server 9.
Two nodes port 9081/9082 running same application but different versions.
Log into app 1. Fine
Change url/port to app 2 it auto logs in, reusing app 1 credentials.
I get an error in the logs at that point that app2 has tried to use app1's soap port.
Everything works fine and can switch ports/ applications without further errors.
Using different session ids for WAS nodes and also different between the apps.
I can only think is some session persistence based on the same domain name.
Please any thoughts on how to resolve this?
Related
I am trying setting up an websphere application server cluster and deploy an web application on it. I have successfully access the application with a web server. but i have some question, if i would access the application bypassing the web server by using 9080 to the single server, i get error when sign in servlet respond.redirect to jsp page. the session was lost, are we not suppose to access the application in cluster environment with out the web server ?
As long as you target an individual server in the cluster, you should not lose your session or suffer any other ill effects for not using/having a proxy server between you and the cluster. You should look closely at the Cookies issued through that flow and make sure they don't have a bad domain or path and that you don't get redirected back through the webserver or otherwise to another JVM.
Also verify there is no DNS-based load balancing. If you don't have session persistence/distribution/replication it won't work.
In our project we are using weblogic server.
If I try to login into our application i.e on machine A, a JsessionId is generated after I logged in.
Now, if I use this same JsessionId on another machine i.e machine B the application will prompt me to home page instead of login page.
Please provide a solution for my problem.
Unless otherwise configured, most servers will destroy any JSessionID it does not recognize and issue a new one. This is to prevent Session Fixation attacks. Java Servlet Engines like Tomcat and Jetty do so as will various j2EE Application Servers such as WildFly(UnderTow) and WebLogic.
If you want to have a session migration between servers nodes you will need to configure your server to do so. Servlet Engines and Application Servers will not do so automatically. You will need to look at your Weblogic docs for your version of your Application Server to determine how to do it.
I will tell you that Wildfly and Tomcat definitely require multicast-ip to make this work. Depending upon your environment it is possible that multicast-ip is blocked by firewalls. Additionally I know, as of this writing, that docker containers do not support multicast-ip out of the box so you will need some sort of work-around if you are using docker containers.
The important thing is that you understand why the session is not automatically migrated and that you need to configure your server to do so. If Weblogic uses multicast-ip that might be another hurdle to overcome.
I hope this helps. This is as specific as I can be as I am not a Weblogic developer.
What you have stated is called session hijacking. There are many good answers on how to prevent it.
Prevent session from being replicated when JSESSIONID cookie copied
What is the best way to prevent session hijacking?
HTTP being an stateless protocol uses a session identifier (mostly a cookie) which is sent with every request which to identify the client. The most common way is to use HTTPS to encrypt your request and prevent anyone in the middle from seeing that session identifier.
One important point to consider is that if the attacker has physical access to your machine, then he/she can easily see your session identifier and there is nothing you can do about it. That's the reason why websites like facebook warn you when you open the browser console and run some scripts.
I'm trying to authenticate on my web application deployed on a jboss working in cluster mode with 2 nodes.
After a succesful authentication I get redirected to an admin page where a Filter checks if I am logged in.
On standalone mode it works just fine but when I deployed into production, which uses cluster mode, the filter rejects my request because it can't access the session parameters I have established on authentication.
Using the developer tools I see there are 3 JSESSIONID cookies set: one for /, one for /myapplication path and another one called JSESSIONID-34234 also for /myapplication path (I've cleared all them before starting the process).
Browsing the jboss docs I can't see no explanation for this although it seems the source of my problem.
How can I get to work authentication (I am using spring security http form based authentication) in my JBoss cluster?
Solved by enabling sticky session by adding the following to the virtualhost configuration file:
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/myapplication" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://jboss6-hc-001-8109>
BalancerMember ajp://jboss2.imatiasl.lan:8109 route=jboss2-hc-001-server-02
BalancerMember ajp://jboss3.imatiasl.lan:8109 route=jboss3-hc-001-server-02
ProxySet lbmethod=byrequests stickysession=ROUTEID
</Proxy>
Web session clustering should work if:
You enabled <distributed/> in web.xml.
Your app's server group is using ha or full-ha profile
If you want your clustered app perform better, consider implementing a good load-balancing policy. For most webapps load-balancing with sticky sessions is OK.
In some webapps, it is enough not to ask for re-authentication in case of failover or session is very easy to rebuild if authentication info is available. In such cases you even don't need web session clustering. Clustered SSO is enough, the caveat is you'll have to use container level security for authentication (most probably supported by spring-security). This way only authentication info is replicated, so you'll have to design session data management to be resilient to situations, when session suddenly becomes empty.
I'm working on a web application that will use Rhino Service Bus to send messages that are then consumed by a windows service on the app server. I've been able to test this on my machine (hosting the web app and the windows service) and it works fine. I was also able to test this in our dev environment, which has one web server and one app server, without any problems. However, our staging environment has two web servers and two app servers, so I'm not sure how to configure the endpoint to which the messages are sent.
I know I can edit the config section for each web server to point to one of the app servers. I can also put the windows service on only one machine and send everything to a queue on that machine. Neither of these sounds like a good option. What's the best practice in a scenario like this?
Any help would be appreciated.
It depends on which transport you're using. If you're using Rhino.Queues you can leverage hardware based load balancing + DNS. If you're using MSMQ, then you would need to use the MSMQ load balancer in RSB. You can find tests in the source that demonstrate this. Your workarounds that you mentioned would also work.
I have a jsf2 app in a jboss 6.x server. From everything I have read here and searching in google, it is always recommended to use sticky sessions. From my understanding, this means that the same node will always be responsible for the requests of the same user. Is this right?
If it is, what is the point of using jboss on a cluster mode? Couldn't I just have two jboss instances and let the load balancer distribute the requests?
The point is that your system is multi-user. When the sticky session is used, the loadbalancer will balance users to both servers and they are used equally. But always one user is doing request to only one server. Advantage of this is that you don't need to replicate session and session data to all servers, which could unnecessary spend lot of resources.
Session replication will help in case of a server shutdown or crash. If the server hosting a user's session goes down, then the user should not be prompted to login again. That is possible only if the user's session is replicated.