I have two application where the login mechanism is through FORM based authentication. The applications are namely "bookapp", "newsapp". The issue is like, I login to my bookapp through internet browser with valid credentials and enter into application by setting respective session parameters required.
Now, I open a new tab and open my newsapp application. Doing this i access my bookapp application and noticed that session has invalidated automatically. It looks like my session is getting overriden here and hence bookapp throws me out.
Please advise if this is an existing mechanism or loading application page using FORM based authentication overrides session.
That isn't a general property of applications which use form-based authentication, no. For example I think you'll find that you are able to remain logged into your e-mail account and your Coderanch account in separate tabs in your browser. So it must be a specific property of one or both of the applications which you mentioned.
But one thing noted in your example is that two applications (coderanch and email a/c) are on different servers and domains. However, in case if I login to Gmail and assume that I have logged out of orkut, my gmail signs me out.
In the issue i mentioned, the two applications are on same servers having different context roots.
After your suggestion, I revisted and noticed that i had below line of code create session. Here, as I login to bookapps application and then load my newsapp and when try accessing any links in bookapps where I am checking the session availability, the application alerts me that session is timed out and vice versa with newsapp because the session id is getting newly created and overriden.
Please advise the best practice to avoid these issues.
I'm not understanding what's being said very well, but I can tell you what should be happening.
When you use container-based authentication and authorization, the actual security functions are not part of the application, they are provided as part of the server functionality, typically via a plugin component called a Realm. Realms come in many flavors, but most of them assume that each webapp is running in its own security context. This isn't always the case, because Realms also exist for Single-Signon where logging into any app in the SSO Realm automatically authenticates you to all other apps in the Realm, but SSO has both pros and cons and isn't used that often.
J2EE tends to be a bit fuzzy in making the distinction between a Secured Session and a Conversational Session. A Conversational Session is the session where your session objects are stored whether you are logged in or not. If you become authenticated, the Conversational Session effectively becomes a Secured Session (or one will be created for you, if no previous HttpSession existed). Invalidating the HttpSession destroys both the Conversational and Security aspects of the session.
In default configurations, each webapp will have its own HttpSession objects for each user with a session (whether Conversational or Secured). This is true no matter how many (or few) servers exist and whether or not they are on the same machine or not. If you are using SSO, the global security profile gets plugged into each HttpSession, but the HttpSessions themselves are discrete. That is, as I said, the default configuration. There do exist ways of sharing an HttpSession across webapps, and even across physical servers, but the exact means of doing so tend to be server-specific.
On the client side, each client instance has exactly one session handle (sessionID) for each webapp that the client is talking to. So each session on the server has a discrete sessionid on the client (fun fact: when you switch from HTTP to HTTPS, the server will destroy the old session ID and create a new one, even though the underlying HTTPSession object remains the same). In other words, no matter how many windows and/or tabs you have referencing a given webapp, they'll all share the same session. However, if you are running multiple client apps (for example, IE and Firefox or 2 different versions of Firefox), those clients will NOT share the same session ID. Each client app instance gets a unique session, even though they're all running on the same client computer.
Sometimes the only way things ever got fixed is because people became uncomfortable.
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop