i hope someone has an answer to my problem.
In our gwt-webapp we use normally the HttpSession to create a user session. So if someone wants to log into our game, we set a session via HttpSession
public void setSessionID(String id) {HttpSession httpSession = getThreadLocalRequest().getSession(true); httpSession.setAttribute("id", id); }
The order of the views is:
LoginView-> HomeView -> LobbyView
Now when going into the lobby, he will be connected with the chat via a websocket Connection. The problem now is, that the websocketConnection will also create a sessionObject i think.
Testing the app on a jetty v-8.1.2.v20120308 shows:
if the first user log into the game and join directly the lobby with chatfunction and another user do it the same way, they can chat with each other- so everything looks fine...
but if the two users log into the game at the same time before someone joined the lobby, and then join the lobby, the second one who has entered the lobby gets all the parameters of the first user who has entered, so that there are both user with the same identity... dont know whats going wrong there.
It seems that the websocketSession from the first user overrides the httpSession from the login of the second player...
thanks for any solutions or ideas which problem this could might be.
This is a bug in Jetty which clear/destroy everything after the handshake. The solution is to close the session at that moment and wrap the request with that fake session. You can also use the Atmosphere Framework[1], which transparently fixes that for you (and much more.
-- Jeanfrancois
[1] https://github.com/Atmosphere/atmosphere
Related
I wanted to know how request objects behave when a session is time out.
To be more specific I came across to one scenario, for which I am not able to figure out what is happening exactly.
The scenario is like this,
I have a login page for my web application with username and password fields. I have set the time out to 10 minutes for my app.
I am on the login page doing nothing for 15 minutes, so the session is timed out.
Now on the login I put the user name and password and hit submit. The page is getting refreshed instead of submitting.
So can I say upon session time out,the request object also times out?
Since you do not add any code to your question, my explanations should be taken with a grain of salt.
IMHO, you are starting the session when a client requests the login page (before he submits the login page) and also you've set it so that a request belonging to a timeout session will be redirected to login page.
So if the result is not to your liking you have to change some of the above.
But again, for a better answer, you have to show us some code.
And for your question about request time out. No it did not time out. It only times out if the server does not respond in time (which is a different kind of time out)
I added some Java code partials which I am using to direct requests belonging to sessions which are timed out to Login page. By the way I also should add that requests which did not require a session is handled before this redirection.
HttpSession session = request.getSession(false);
boolean hasActiveSession;
if (session == null) {
hasActiveSession = false;
//...
}
//...
if (!hasActiveSession) {
request.setAttribute("alert","Your session has timed out");
request.getRequestDispatcher("/WEB-INF/Login.jsp").forward(request, response);
}
I am trying to implement the functionality with which , when a user is loggedIn at one place and when he try to login to some where else , He should automatically be LoggedOut from the previous place .
Like in GMAIL..
If some one can give me the concept , As i think I need to save the user LoggedIn Status in Db,As sessions doesnt looks to be heplful. But then I dont understand how we update user status in DB ,if there is no activity for lets say 5 minutes (how will i capture the inactivity and updating in db).
If some one can please guide, I am struggling on this for hours now .
Thanks
When user login add the user session with id to a hashmap. When the same user logins again check for entry in the HashMap and if available invalidate the session and create new session for the user.
If you are using Spring Security, it provides this functionality out of the box.
Otherwise:
Create a java.util.Map (A ConcurrentMap is prefered, so manipulating it concurrently won't corrupt it), and stores it in application scope (ServletContext).
Now, you shall store each user and a reference to its session upon login in the map, and if a user logins again, just fetch previous session object and invalidate it.
Now implement an instance of javax.servlet.http.HttpSessionListener, and in void sessionDestroyed(javax.servlet.http.HttpSessionEvent httpSessionEvent); method, remove the specified session from the Map. (This listener is invoked on session invalidation, whether it is done automatically by container or if you do it programmatically). just register this listener in web.xml and everything is done.
p.s. I know that it will be some-how harder, if you are deploying your application on a cluster of web-containers, but when you have just one server, that's ok.
p.s. I don't recommend storing session information in DB.
Suppose, a use login with username="ABC",
Some data is set in the session as follows:
session.setAttribute("mydata", mydata);
If the current session expires, the user is redirected with login page.
And now, if the user again login with same username ("ABC"),
Can we retrieve the previous session's attribute so that the user can continue his work?
Please suggest me the possible solution to retrieve the data of previous session.
Thank you.
I don't believe it is possible . However, you can always create a semaphore where your app can check against it whenever the user logs in and invalidate the session if there's already an existing user session running.
This semaphore could be as simple as a Java static variable if you are running in a non-clustered environment, or a better approach is to set the flag in a database table especially if you are running in the clustered environment.
Not possible, when the session expires everything it contains is dead. This is controlled by the container.
You could save session attributes to database beofre they expire, then add them back to the new session when user logs in again.
During the Application startup , using the login Id of the User , i am making a Database call and loading all of his accounts and setting them in the session as shown
session.setAttribute("userinfo",userinfo);
and i am using this accounts information in the service layer to do a check before making a call to the Database
Now the problem is that if a User (who is having multiple accounts ) logs simulatunosly into a same browser , its creating same sessionid , as a result the session is having only the information of the last logged in user .
is there anyway i can solve this , may be the way i am storing data
please help
May not be the best solution but this will help to solve the problem.
What you could do would be to associate the userid with the sessionid and on every pageload / clicks, you will check if the sessionid matches the login user's userid. If it matches, disregard and run the page as usual else you can fetch the user info from the database and reassign the variables again.
You can use URL rewrite instead of cookies. The downside is that the session ID is exposed in the URL.
I have a very basic Wicket app that I'm trying to deploy to GAE. I have the basics working, after following the steps here and also binding the session object upon creation.
I'm having trouble saving any state in a session. My session class extends AuthenticatedWebSession. The login pages authenticates via AuthenticatedWebSession.authenticate(), which always returns true and sets the username in a member variable. But subsequent pages see a null username in the session and AuthenticatedWebSession.isSignedIn() returns false.
I do seem to be maintaining a session, as every page will see the same value for Session.getId().
Any ideas?
TIA!
Chris
My question was answered on the Wicket mailing list - the answer is that I needed to call Session.dirty() after authenticating (or after any other change to the session members) to ensure it would be saved. Apparently in my development environment, sessions were always saved but GAE is more optimized and thus only saving dirty sessions.
I spent about 2 days devling down the rabbit hole of sessions and cookies and I finally realised my issue was this:
app.secret_key = os.urandom(50)
Every time an instance boots up it generates a new key and now the users session is lost.
You need to make your key static
app.secret_key = "really-complex-key-that-is-static-and-never-changes"
Hopefully this is your issue to