This content has been marked as final. Show 12 replies
My Web application is running in 3 Web servers , means same war file is running in 3 differend M/C.
I have a requirement to limit more than one login with same user id . Meaning one user can login only one time.
We dont use clustering because of server investment.
Say for example, User login to My application.
We Should check all 3 Web server to decide he is logged in already or not. If He is already logged in we need to show confirmation page that you have a session already. You want to overwrite old session ? If he say yes, We need to remove old session and have to add new session .
Previouse we had stored session into table, using that we will check whether he is logged in or not.
Now we dont want to use table, so what we did, we form a key using user id + etc.., We use it as a key and store the session object into application.
When user say he want to overwrite old session,
we know the key of user, using that we refer his session and call invalidate method to remove a session from application.
I know the soln, bit complex , so you pls help me on that how could we
replace old session with new session , as we want to avoid concurrent login.
Well, place identifying information in the session and keep a hashmap in the servlet context with this identifying info as the key and the session as the value. Then, you may be able to call session.invalidate on it. Then, again, it may throw an error when you do this.
But of course, there are security issues with this, as all the session information is accessable to all servlets (they simply need to call servletcontext and retrieve the hashmap) so you should provide access only specific sessions from the servlets through a method where the servlet must provide the identifying info in order to retrieve the session. And hopefully this info is not readily available to all servlets.
But I do believe I was right in the "mad hacking" assessment, it is just not your fault, but your companies.
How your differing servers communicate with each other is your decision though. Maybe through a program that is started through a context listener and opens an ssl socket for receiving and handling these session requests.
What about the instances' communicating each withThis is a good method. Use a session listener though, to remove the "logged in" entries when the session expires though.
other through a database?
It would not be that difficult to track the logged-in
users in the data base.
Edit: But then again, he needs that with the servletcontext hashmap as well. And even in the db method, the session still needs to be saved in the servletcontext, otherwise he won't be able to remove it.
Just a few stray thoughts :-)
We remove the user session though HttpSessionListener. Previously we had stored the session id into active_user table. When user try to login we select info from the table ( meaning session id of user) , then we will know to where he is logged in ( Web server - 1 , or 2 or 3 ), then we will check that still he is active , if yes we will not allow him to login again.
But now they dont want active_user table, that is why we dont want to deal with session id , but now deal with user id as a key.
Note : Mod_jk is used to balance the load. It decides the user which app server he should use.
is there any way to invalidate a session using session id ?
session.invalidate() is trigger the session listener to remove the user from the server.
In my case, at one point of time i should invalidate a user session , i dont have session object, but some how i can get sessionId, may be from table or from hashmap, pls advise me.
The reason was storing session object application is that we should invalidate Previouse session before he is allowed to login again.
That is reply number 3. Simply have the servlet retrieve the servletcontext and store the session as a value in a hashmap there. Then, the program that gets started by the contextlistener can retrieve that session from the servletcontext, call session.invalidate on it (and this is the way that you remove a session), and remove it from the servlet context hashmap. Like I said, the communication between the servers will be the difficult part, if it is not a cluster.
That is the reason I mentioned a program started by a ContextListener that opens a port (preferably an SSL port) that can be used for the inter-server communication for the removal of sessions. Whether the connection is a persistent stateful connection or a connect on request connection is up to you (I would use a persistent stateful connection for speed considerations).
Well :) thx for ur reply .The concern came up from my team mate that why should we store session object into application.
1 ) It looks like security loop hole. Whereever you access application object , internally you are able to access session info of every user.
2 ) Second issue, As we have 10,000 + users , if we store all the session object into application it may cause server crash ?
3 ) At present , we communicate to other web server HttpPost using object pipe.
Well, it has to be stored somewhere. And the ServletContext already has it anyway as the session exists. This is only creating another reference to something that already exists, so the memory addition is minimal.
Anyway that you do this will be a security concern, as regardless to how you do it, whether it the application or the servletcontext that stores these, the application will probably be able to get at it. The program started through the ContextListener can be stored as a context attribute and let a method in that class be called to store session attributes but never release them to any servlets (the servlets get the session object the normal way). Then have this class only remove the sessions if notified from the SessionListener Class (place it in the same package and make the method protected) or if requested through the SSL port (maybe use RMI with another class from the same package for the protected method access).
The SSL port suggestion was purposely placed in order to suggest using a method for this that is seperate from your other operations. If your servers are not locally accessable, however, this may be a problem. Try implementing the above with your object pipe.
We already remove the session object through object pipe.
Meaning we invoke a servlet with some " key " through object pipe,
then that servlet invalidate the session object which is a value of a hashmap which is stored in ServletContext(application)
What i understand from your previous reply,
1 ) If we store session object into Servlet context, there is no memory issue or might be minimal.
2 ) There is a secruity issue, in order to avoid that, we may use
either SSL or RMI or request a servlet using object pipe ? Is that correct ?
For point number one, there is memory usage, but it is minimal.
For point 2, if you are using httppost and an object pipe to do your removal, then do the following 2 things to satisfy security demands:
1) use https not http (SSL not PlainText)
2) use some additional sort of authentication in your HttpPost (maybe simply an additional few parameters with set (or, even better, generated) values)
The above two points will keep anything else from being able to easily use an HttpPost of their own to try and either foul up or invade your server. The first by encrypting your communication, the second by requiring authentication.