Scope of an HttpSession

[Po-yu Chien]

In Tomcat, an session belongs to only one web application. That`s a problem, because if you user session for user authentication, user may need to login multiple times switching between web apps. Is that a Tomcat-only behaviour?How to overcome it?

[David O'Meara]

I'm currently researching the same thing (although in relation to Websphere 4).
Allowing multiple web applications to run within a single application server is a convenience and performance thing. It should also (however) provide safety between the applications, so that if a person log into app1 they aren't logged into app2.
Knowing that two applications are running on the same server should allow a developer to explicitly communicate between the two in a controlled manner. You don't want them to accidentally overlap (such as the above example), but there should be some some ability to talk...
There is the ServletContext.getContext(name) to return a handle to another named context, but this doesn't give access to the session.
I had a play with Websphere4 and did this:
/session1/one.jsp - reports the session Id, puts some data on it and reports if the session isNew
/session1/one1.jsp - reports the session id, reads the data on the session and reports if the session isNew
/session2/two.jsp - reports the session id, reads the data on the session and reports if the session isNew
Sample response is:
one.jsp - reports the ID (eg something like JHGJHKJHKHGKHGKHG), prints the data from the session "string", and reports that the session is new (ie true)
one1.jsp - reports the same ID but this is expected, prints the data from the session "string" (again, expected) , and reports that the session is NOT new (ie false) again again, expected behaviour.
Now the tricky bit:
two.jsp
- reports the same ID as the other context (so far not too wierd),
- does not find the data stored on the session (in the other application context)
- reports that the session is new, even though it has the same ID
So, the ID is the same and could lead you to believe that the session is shared, but it is not. Therefore the behaviour you saw is not just Tomcat related.
I have had it suggested that you can use the session ID as a unique key to communicate across web apps. But I'm still not convinced.
Anybody?
(oh, and I haven't tested for the same behaviour in Tomcat or read the spec to see what it does...yet)
Dave

[Po-yu Chien]

If it were for merely authentication, I think going back to the OLD way--setting cookies--would be ok. But sometimes you would like to share some session data which may not be so adequate to expose to user through setting cookies. Now the protection brings inconvenience.
The solution I found is to use perhaps encrypted url rewriting whenever session data between two apps must be shared. That`s an ugly solution, and I hope someone can bring up something better

[David O'Meara]

Sorry, I had ignored those aspects since my requirements also include FORM based authentication (ie implicit rather than explicit), so COOKIES and passing bulk data around isn't really an option.
Dave

[hob hartman]

David,
I am not sure if I understand your problem so feel free to correct my impression. I have three jsp's: hello1, hello2, and hello3.
hello1.jsp
<%@ page session="true" %>
<%
Integer num = new Integer(100);
String id=(String)session.getId();
session.putValue("num",num);
String url =response.encodeURL("hello2.jsp");
out.println("Num value in session is: " + num.intValue());%><BR><br><%
out.println("Session id is:" + id);%><br><%
out.println();%><br>
<a href='<%=url%>'>hello2.jsp</a>
hello2.jsp
<%@ page session="true" %>
<%

Integer i= (Integer )session.getValue("num");
Integer anothernum=new Integer(102);
session.putValue("num",anothernum);
String id=(String)session.getId();
String url =response.encodeURL("hello3.jsp");
out.println("Num value in session is "+i.intValue());%><BR><BR><%
out.println(id); %><br><br>

<a href='<%=url%>'>hello3.jsp</a>
hello3.jsp
<%@ page session="true" %>
<%
String sameid=(String)session.getId();
Integer k= (Integer)session.getValue("num");
out.println("New num value in session is " + k.intValue());%><br><br>
<%out.println("Session ID is: " + sameid);
%><br><br>
I used the session object and created a "num" property in hello1 which I gave a value of 100. Then linked to hello2. In hello2, I created a num Integer object to carry the session "num" property and allow the data to persist into hello2. Then in hello3, I did the same essentially except I changed the session "num" value to 102. All my session ids are the same.
New objects in each application to carry the session propertys which are themselves objects.
Am I missing the point as to what you are looking for?
hob

[Mike Curwen]

hob,
What they are talking about is if hello1, hello2 and hello3 were in three separate applications, in other words:

CATALINA_HOME
 webapps
   webone
     WEB-INF
        hello1.jsp
   webtwo
     WEB-INF
        hello2.jsp
   webthree
     WEB-INF
        hello3.jsp

[David O'Meara]

Mike's right, the problem is sharing information across separate applications running on the same server.
(Actually I'm talking about trying to simulate a single login across multiple applications - with Form based authentication thrown in, Po-yu Chien is talking about mostly the same thing, but sharing the session as well)
I ran the same test on Tomcat 3.4.4 and 4 and got the opposite results from the Websphere4 test (I could run it on WS3.5 and some others too, but I'm not gonna) and got completely the opposite result
and , possibly or
On Tomcat, the session IDs are different and a new session object is created in each application, but the data from the first session is available
Dave

[Po-yu Chien]

Thanks David.
I didn`t notice that data are avialable between webapps in Tomcat. However, since application servers are not expected to behave in the same way here, therefore I cannot rely on this Tomcat specific feature.
Seems that there is no good way for cross app authentication

[David O'Meara]

There may be...
Web Applications running on the same server can share info using the ServletContext to get a context to another application...

ServletContext otherContext = getServletContext().getContext("/session2");

This allows you to access a RequestDispatcher to access resources on the other context, and that resource will be passed the same request and response instances...

otherContext.getRequestDispatcher("two.jsp").forward(request, response);

I haven't tried it yet (and I would want to test it in WS and Tomcat first), but if you can get the user to perform an operation like this before they access the other app, you should be able to pass the session data to the other app and then the problem becomes how do match the users between the two requests...
Dave

[Mike Curwen]

David,

To speculate on your ??

Presuming: Sessions are not really shared, merely cloned and kept synchronized...

Having two different sessions with the same number is asking for trouble. session1 is in webapp1, and is a clone of session2 in webapp2

I've read through the servlet spec (perhaps the wrong place to be looking??) and it seems fairly silent on this issue (cross context sessions).. Tomcat does implement it though, it's a setting in server.xml, which by default is "false" (don't share sessions)

[Parag Shah]

If I understand correctly, the problem is of a single-logon accross multiple applications. Perhaps using servers may solve the problem.
The user communicates with serverA which has a facade application which in turn communicates with multiple applications deployed on ServerB. The mail role of the facade app is to pass on all http requests to serverB and all responses from serverB to the user. Beyond this the facade app will authenticate the user once and programmatically perform multiple authentications for the user on serverB such that it is transparent to the user.
This is just an idea I had, though I am not perfectly aware of what issues may crop up in such a scenario.
Parag

[hob hartman]

And why can't we, or why don't we want to, persist the data in a database perhaps using a JavaBean to create our db connection and to get and set our login info?

[Po-yu Chien]

Of course you can store login data in database, however this still fails to address the user<->data matching issue, unless you develop your own matching mechanism. And IMHO it`s not a good idea. By the time when I was using PHP, I already tried storing session data in DBMS in order to achieve cross-server session synchronization, and it does not scale well.
As for the Facade application that handles authentication....that`s nice. In fact, that appears to be how will single sign-on look like with web services(theserverside.com has an article on this). But I don`t think this may be a solution for those who uses application server`s security model. It`s strange that servlet spec does not bring up this issue

[David O'Meara]

The Websphere portal server (whatever that is) supports single login, but I get the feeling they do it via the Facade solution. That is, everything exists as a single web app at the application server level.
I also looked at the ability to store data at the back end, and the solution was like this:
User is in app1 and clicks a link on app1 that leads to app2. This link includes a key (separate to the session ID) so that the same unique value can be sent to the client and then to app2 by the client, and it can also be associated at the back end with the users credentials.
When app2 recieves the unique identifier, it uses it to provide the single logon. The problem is that it requires an explicit action by the user (ie 'I am going from app1 to app2') otherwise you end up storing the data at the back and all the time.
I still have several issues with it...
Dave