session object behaves like application (scope)

[Alan Yap]

This said problem had been bugging me for years (I mean my failure in helping them to solve the issue). The web app was deployed to client's server for over half a decade.Though they had found a workaround (non-coding-wise), I'd think I want to put an end to this.

computer A (where the app is deployed),B,C are networked to each other.

User A,B,C uses our web app on their respective computer (no login mechanism in my web app).

In some modules, I created a session scoped object X (hashtable to be precise). The problem is, its not exclusive to each user. For eg. when user A access the module, user B lost her content stored in X. It behaves exactly like an application scoped object.

During development in my machine, the problem never exist at all. Is this a problem related to their network configuration the prevents the jsp engine from working properly ? I used a pre-2005 version of Tomcat back then.

[Devaka Cooray]

More likely it's something up to the container provider.

[Vijitha Kumara]

To identify a client what mechanism you are using (though you don't have a login mechanism), cookies or ...? I'm not sure about pre-2005 servers . Any specific API versions? Have you check this in a new container, perhaps Tomcat 6 ?

[David Newton]

With no code it's impossible to help. I don't see how other machines on a network could possibly affect the JSP engine on a different machine.

[Ben Souther]

You might want to start by getting your app running in an up to date version of Tomcat.
I know a lot of the session replication code stuff has been rewritten since somewhere around Tomcat 4.

[Alan Yap]

Vijitha Kumara wrote:To identify a client what mechanism you are using (though you don't have a login mechanism), cookies or ...? I'm not sure about pre-2005 servers . Any specific API versions? Have you check this in a new container, perhaps Tomcat 6 ?

Ben Souther wrote:You might want to start by getting your app running in an up to date version of Tomcat.
I know a lot of the session replication code stuff has been rewritten since somewhere around Tomcat 4.

Well that was the very 1st version of the web app I developed for the client. I have moved on to Caucho Resin since then (due to hosting requirement, I maintain my company's website as well). Their (client) service contract had ended too so we're not obligated to do anymore updates for them. Subsequent version of my web app have been re-developed from scratch/delivered to other clients and this issue never crops up.

The reason I start this thread is to find out:

- the chances of server/network configuration to cause the problem I stated
- to find out logical explanations and other possible causes, so I can be wary in the future and know where to debug if it occurs again.

I always have this fear of encountering this problem (again) everytime I install/deliver our product to the client, even though it occurs only once.

Thanks guys. This rock on my back have suddenly shrunk to a pebble.

[ramprasad madathil]

Even with a pre-2005 machine and dated apis, it's hard to believe that something as basic as session management will have such a fundamental bug. I would be inclined to think that it's more probable that it's a logical bug in your application. As previously pointed out, it's difficult to speculate on a cause without any code. Here are some things worth investigating

1. Given that there is no login, how do you create a session? What mechanism do you use - the standard request.getSession(true)? At what point in your app flow does that happen? After a session has been created, how do you retrieve the session in later requests?

2. What is the session invalidation interval? Do you use file cookies or per browser cookies for session? Is there a logout functionality in your application?

3. Do users log on from the same machine?

4. Do you store reference to session objects on the server in application scope?

ram.

[Alan Yap]

ramprasad madathil wrote:Even with a pre-2005 machine and dated apis, it's hard to believe that something as basic as session management will have such a fundamental bug. I would be inclined to think that it's more probable that it's a logical bug in your application. As previously pointed out, it's difficult to speculate on a cause without any code. Here are some things worth investigating

1. Given that there is no login, how do you create a session? What mechanism do you use - the standard request.getSession(true)? At what point in your app flow does that happen? After a session has been created, how do you retrieve the session in later requests?

2. What is the session invalidation interval? Do you use file cookies or per browser cookies for session? Is there a logout functionality in your application?

3. Do users log on from the same machine?

4. Do you store reference to session objects on the server in application scope?

ram.

1. most of the jsp pages/modules simply display a form and process user submission. Only a few modules require some data to be put into session (hashtable) to be utilised in other pages.

2. I didn't tweak the interval. If I'm not wrong, the default value would be 30 minutes, right?

3. users access the web app from their respective machine via http://machinename:8080/appname (the web app is deployed to one of their machine).

4. dead sure it's session.setAttribute("VAR", MYHASHTABLE);

=========================

Latest update!

This problem occured again today to a complete new webapp we have developed for the client (not related to the one above)

- webapp (using Resin 3.0) deployed to server (Windows Server 2008)
- computers in the lab accesses it via http://machine-ip:8080/newapp
- user logs in using their respective account
- the jsp engine only "remembers" one single user session (latest).

In the lab, scenario of what had happened:

1) user A logs in our webapp using computer A successfully using his user ID/password. his browser display "welcome user A".
2) user B logs in using computer B successfuly, his browser display "welcome user B".
3) Now user A has lost his session, overwritten by user B's. When he clicked on refresh on the browser, it displays "welcome user A" instead.
4) Even without logging in , the session "persist" to all the networked machines there. loading "http://machine-ip:8080/newapp" directly from other computers there, will display "welcome user A". (very "fatal" security breach there)

The problem doesn't happen in the actual server where the webapp is deployed:- http://localhost:8080/newapp. All the sessions created by user logins in multiple browser instances are unique.

There is an annoying problem that I wonder might be related to the problem above:

1) main page detects not logged in, display login form
2) user logs in successfully, redirectly to the same main page
3) instead of displaying "welcome user" and hiding the login form, it serves the previous page (cached, displaying the form). I need to refresh the browser once to get intended "welcome user" page.

My codes:

in jsp page:

    <jsp:useBean id="USER" scope="session" class="newapp.user"></jsp:useBean> 

in newapp/user.java

 package newapp;

import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class user implements java.io.Serializable

{


   public String ID=null;
   public int TYPE=0;
   public int STATUS=0;

   public String NAME=null;

   public boolean ISLOGGED=false'

   public Hashtable SETTING = new Hashtable();
	
   public void set(String NEW_NAME,int NEW_TYPE)
   {
   	NAME=NEW_NAME;
   	TYPE=NEW_TYPE;
   	
	ISLOGGED=true;

   }

   public void logOut()
   {
   	NAME=null;
   	TYPE=0;
   	ISLOGGED=false;
   }

}
   

I'm at a loss here in finding out the root cause. Hope fellow ranchers can point me to the right tree to bark on.

[Vijitha Kumara]

Is the application consists of only JSPs and POJOs?

[Alan Yap]

Vijitha Kumara wrote:Is the application consists of only JSPs and POJOs?

Well, nearly all the class file extends HttpServlet, except for the one session object (user.java above) that implements java.io.Serializable. There rest are jsp files.

I've been searching high and low for the solution (here and in other sites) and come across a few links with the same problem as mine. "session mixup" would be better to describe it. (below). Alas but none of those links provides a solution.

https://coderanch.com/t/357495/Servlets/java/Session-Interference
http://www.thatsjava.com/java-web-tier-apis/64642/
http://www.mail-archive.com/[email protected]/msg155750.html

Resin documentation suggested a few areas can I look into:

http://wiki.caucho.com/Losing_session

Problems with cookie domains
You may also lose your sessions if your cookie domains are incompatible. For example, if you have one server that uses cookie domain "hogwarts.com" and another that uses "qa.hogwarts.com", the cookie in the browser for "hogwarts.com" will interfere with sessions on "qa.hogwarts.com". The solution is to change the cookie domain "hogwarts.com" to "www.hogwarts.com".

You set the cookie domain in session-config.

Since my app is deployed on an intranet environment, (no domain name) , what shall I use as the cookie-domain value? the ip or the server name?

[David Newton]

You can check to see if cookies are being sent/received properly by looking in the headers. It could also be as simple as not understanding how servlets work and using instance variables. Without the actual code dealing with sessions it's impossible to help.

Is there any reason the newapp.user class breaks most Java naming conventions?

[Alan Yap]

David Newton wrote:You can check to see if cookies are being sent/received properly by looking in the headers. It could also be as simple as not understanding how servlets work and using instance variables. Without the actual code dealing with sessions it's impossible to help.

Thanks for the suggestion. definitely will do that on my visit to client's place tomorrow.

I tried hard to replicate the problem for the past few hours. Just set up and tested my newapp in a networked environment. Pretty simplistic actually:- connecting my laptop (host) to my home computer (client) via direct cabling. The problem failed to surface. It works perfectly, sessions are unique across different browsers in the client via "http://alanlaptop:8080/newapp". I am ruling out logic error. Previous customers of ours have been using the same app/codebase we developed for years with no problem.

I over-step my "range" of search by googling non-jsp related session mixup. A few ASP.NET coders and PHP programmers encountered the same problem. I am suggested to focus on server proxies that messed it up. It's making more sense now to me (and its not because of the good jolt of caffeine I had just now).

qouted from http://shiflett.org/articles/the-truth-about-sessions

Of particular note in this example request is that there is nothing within it that can be used to uniquely identify the client. Some developers resort to information gathered from TCP/IP (such as the IP address) for unique identification, but this approach has many problems. Most notably, a single user can potentially use a different IP address for each request (as is the case with large ISPs such as AOL), and multiple users can potentially use the same IP address (as is the case in many computer labs using an HTTP proxy). These situations can cause a single user to appear to be many, or many users to appear to be one. For any reliable and secure method of providing state, only information obtained from HTTP can be used.

The lab computers in our client's place where I tested my newapp suffers from the same fate. Oh yes one more thing. The server where I deployed this newapp of mine is managed by Windows IIS6 . As someone who is not so well-versed in network configuration, what do you guys suggest I do to get my app back running ok again?

David Newton wrote:

Is there any reason the newapp.user class breaks most Java naming conventions?

:( old habits die hard.