I have a requirement for handshaking between two different web applications (a Client and a Server - "ClientApp" and "ServerApp") in the same Tomcat Server Instance. Basically I implement a custom 2FA (Two factor authentication of my own) which involves two steps.
Client handshakes with the Server first for getting a token
Upon receiving the token from Server, the client prepares the 2FA data and sends it along with the real user data for authentication. -- This is to avoid the illegitimate requests if any.
My search resulted me with two different options. One is to use a Web service (irrespective of the server instances) and another was to rely on cross context by setting crossContext=true in the context.xml of Tomcat Server if both the web applications reside in the same Server.
I have set the crossContext to true in the context.xml of my Tomcat server and the issue seemed to have got resolved. However, all was well for just one time. My requirement is to have the interaction more than once. The second time, though the Context for the "/ServerApp" is NOT null, the control does NOT get forwarded at all.
Is there anything that I need to further to have repeated interactions between two different Web applications deployed in the same Tomcat Server Instance?
Thanks Tim for your reply. For the time being, I made a work around. For my first interaction (which is just a handshake of token exchange), I had used a Http URL Connection and for the second interaction I use a http redirect, which seems to have solved the purpose. However, I would certainly want to complete this thread for my knowledge.
Tim Holloway wrote:The crossContext option should be less overhead, but as with all optimization tricks, you should first make certain that the loss in flexibility is going to be worth the risk.
This is the first time I am encountering the scenario of using crossContext and hence I am not of aware of the nuances if any. I have been searching in Internet including Apache website but nothing much to avail directly. All what I get is a precise info on the benefit of crossContext being set to true. Can you please help me out in understanding the flexibility loss that you had mentioned, along with the potential risks if any?
Tim Holloway wrote:I can only make a wild guess what might be going wrong lacking further details, but I'd suspect that the second request may not be happening under the context that you think it is.
I also had this doubt but could not complete the knots. When the first call is successfully made after obtaining the context to Server application, I am indeed obtaining the context of Client application to return the response. Do you mean to say, it is not actually happening? Let me try printing the context objects again to verify the same if it helps. Meanwhile, can you please give me any pointers on this?
When you make a non-crossContext request from one webapp to another, everything has to be set up from scratch. You may save some overhead if both webapps are on the same machine, since instead of being routed through relatively slow hardware interfaces the actual network request would go through the in-memory loopback device, but that's about all.
On the plus side, that means that you don't have to have both webapps in the same instance of Tomcat or even on the same physical/virtual machine. So you can move them around, cluster them, load-balance or whatever.
The crossContext environment is a more direct channel from webapp A to webapp B. Since both webapps are going to be in the same instance, they can share data more directly and not have to compose or digest the full HTTP stack worth of information. But the cost is that they must both be in the same Tomcat VM (or maybe in the same cluster, via serialization).
As far as the second question goes, I'm just making a wild guess. I cannot really tell what's going on there without actually having to work for a living there.
Being persecuted doesn't in any way prove your righteousness or your beliefs. Many people get persecuted because they are repugnant or annoying. Or just because they can be.
Tick check! Okay, I guess that was just an itch. Oh wait! Just a tiny ad: