The typical approach to handling sessions in Java EE is by utilizing the HttpSession interface. The limitation of this is that your sessions are stored only on a single server unless you are using some sort of clustering application server.
In my case I am using Tomcat. What I would like to do is design a web application with a RESTful backend that could span multiple virtual servers. Because it is not contained to a single server using HttpSession will not work for my purpose (I have not investigated clustering with tomcat yet). My need for a stateful session is that I have to maintain stateful authentication. I decided on using JSON Web Tokens (JWT) to do this job. After days of looking at debates over how to properly use them I decided on placing them in an HttpOnly cookie, much like the way Java application servers store HttpSession IDs in the browser. And store a unique identifer from the JWT (the jti claim) in a database. At this point what I have really done is implement my own session management logic.
Now that I've explained what I've done, please rip it to shreds. Tell me what I did right and what I did wrong. I need feedback. I'm not sure if this is a good idea.
I guess you can achieve this via In Memory DBs such as H2 or Redis. Which can help you to store the session token/cookies in the memory and you can implement such a way that the session authentication is done irrespective of the virtual server. In short the session wont depend upon the servers to which the request is being forwarded.
Why fit in when you were born to stand out? - Seuss. Tiny ad: