It is often the case that a large project is split into small projects that require each small project to be developed as a separate Web application to be able to interfere with each other, but at the end of the day there is a sudden discovery that a few small projects need to share some information or want to use the session to implement SSO ( Single sign on), saving login's user information in session, the most natural requirement is that applications can access each other's sessions.
However, according to the servlet specification, the scope of the session should be limited to the current application, where different applications cannot access each other's sessions. Each application server complies with this specification in real terms, but the details of the implementation may vary, so there are different ways to resolve sharing across application sessions.
First, let's look at how Tomcat implements session isolation between Web applications, and from the cookie path set by Tomcat, it is different for the cookie path for different application settings, so the session IDs used by different applications are different. So even if you are accessing a different application in the same browser window, the session ID sent to the server can be different.
The author used before the iplanet is also used in the same way, estimated SunOne and iplanet will not be too big difference. For this kind of server, the solution of the idea is very simple, the actual implementation is not difficult. Either have all the applications share a session ID, or have the application get the session ID of the other application.
In iplanet, there is an easy way to share a session ID, which is to set the cookie path for each application to/(in fact, it should be/nasapp, which acts as the root for the application).
<session-info>
<path>/NASApp</path>
</session-info>
It should be noted that the session of the operation share should follow some programming conventions, such as adding the prefix of the application to the name of the session attribute, so that setattribute ("name", "Neo") becomes setattribute (" App1.name "," Neo ") to prevent namespace collisions, resulting in overwriting each other.
In Tomcat, there is no such a convenient choice. On Tomcat version 3, we can also have some means to share the session. For Tomcat above version 4, the author has not yet found a simple solution. Can only use the power of a third party, such as using a file, database, JMS or client cookie,url parameters or hidden fields and other means.
Let's take a look at how WebLogic server handles sessions.
You can see from the screen screen that the WebLogic server has a path to all the cookies that are set by the application, does this mean that the session can be shared by default in WebLogic server? However, a small experiment proves that even if different applications use the same session, each application can still access only those properties that it has set.
For such a structure, it should be impossible to solve the problem of session sharing in the session mechanism itself. In addition to the power of third parties, such as the use of files, databases, JMS or client cookie,url parameters or hidden fields, and other means, there is a more convenient way to put an application session into the ServletContext, This allows another application to obtain a reference to the previous application from the ServletContext. The sample code is as follows,
Application A
Context.setattribute ("Appa", session);
Application B
Contexta = Context.getcontext ("/appa");
HttpSession Sessiona = (HttpSession) contexta.getattribute ("Appa");
It is noteworthy that this usage is not portable, because depending on servletcontext Javadoc, the application server can be in a safe cause for context.getcontext ("/appa"); 8.1 In the passage.
So why WebLogic Server set all the cookie paths for the application to/? Originally for SSO, all applications sharing this session can share authenticated information. A simple experiment can prove this by modifying the descriptor Weblogic.xml of the application that first logged in, modifying the cookie path to/appa access to another application will request login again, even if in turn, access the cookie path/application First, Access to this modified path, although no longer prompt for login, but logged in user information will also be lost. Note that the authentication method should use form when doing this experiment, because the browser and Web server have other way to the Basic authentication method, the second request authentication is not through the session to realize. Please refer to [7] secion 14.8 Authorization, you can modify the attached sample program to do these experiments.
Summarize
The session mechanism itself is not complex, but its implementation and configuration flexibility makes the specific situation complex and changeable. This also requires that we do not use a single experience or a browser, server experience as a universally applicable experience, but always need specific circumstances specific analysis
