sessions ids getting overwritten for same user

[aditi]

User A logs in with valid credentials and a session id is generated for user A. -  this operation is done on tab 1

Same user opens a new tab in same browser and launch the application again and is directed to login screen.

After logging in, we observe that new session id is created for user A. -  this operation is done on tab 2

 

Now whenever user performs any operation in tab 1, session id of tab 2 is seen.

Due to which we are facing issue of data overlapping.

 

Not able to understand why in first place the latest created session are getting carried over to all tabs. Is there something we need to take care as part of session management at server side?

 

Please suggest

[Thomas Broyer]

On Monday, February 10, 2014 11:13:50 AM UTC+1, aditi wrote:

User A logs in with valid credentials and a session id is generated for user A. -  this operation is done on tab 1

Same user opens a new tab in same browser and launch the application again and is directed to login screen.

After logging in, we observe that new session id is created for user A. -  this operation is done on tab 2

 

Now whenever user performs any operation in tab 1, session id of tab 2 is seen.

Due to which we are facing issue of data overlapping.

 

Not able to understand why in first place the latest created session are getting carried over to all tabs.

Because you're using cookies, probably.

 

Is there something we need to take care as part of session management at server side?

You shouldn't use "sessions" (as in, javax.servlet.http.HttpSession), except possibly as a mean of identifying a logged-in user (rather than roll your own).

Next, if you do use cookies (and you probably will, whether consciously or not, whether willfully or not), then keep in mind that a cookie is shared with the whole browser on the client side. That means that when you open a new tab in the same browser and "launch the application again", you should be automatically signed-in (because the browser sends the cookie for the session you first created in the first tab), not directed to the login screen. If you do want that latter behavior (login per tab, rather than per-browser), then do not use cookies, and do not use "sessions" (javax.servlet.http.HttpSession) on the server side: issue a "token" that the GWT app will send with each request and can be verified on the server side (which probably means it should be stored in some database/datastore, but not necessarily, if you use a signature mechanism instead; server-side storage of the token however means you can revoke it at any time, which can be a great feature [1]), this is your "session", manually managed, cookie-less session.

[1] See https://github.com/blog/1661-modeling-your-app-s-user-session for a discussion on the subject

[aditi]

Thanks Thomas!

That helped me to understand this better.

Ideally, we should allow the user to automatically get into the application who has already logged in (per broswer).

But server code generates session id with every launch of application sets the value in cookie SESSIONID.

Please suggest how should we handle that?

[Thomas Broyer]

[back to the group]

On Mon, Feb 10, 2014 at 4:40 PM, aditi <17.a...@gmail.com> wrote:

 

 

Thanks Thomas! That made it a little better for me.

Actually I should allow user automatically get into the application when logged in once in the same browser as you mentioned too.

But the code at the server side generates session id and sets the value in cookie SESSIONID and overwrites the previous value.

How should I stop doing that,.

You shouldn't; generating a new session just after you verified the user's credentials is a good practice.

What you should do is check that there's a session before displaying the login screen; but then it depends what "displaying the login screen" means in your app.

The easiest way to do it is to just use a <login-config> in your web.xml so you don't have to do anything in your GWT app: when the app loads, you can be sure that the user is authenticated (note: you should probably also setup an XSRF protection). What I like to do is to use a dynamic host page where I can generate some script with information about the current user, that will be read by the GWT app using a Dictionary or JSNI (you can also generate an XSRF token and pass it to the app that way).

See the gwt-rf-activity archetype in https://github.com/tbroyer/gwt-maven-archetypes, which does just that.

[Lohmar ASHAR]

Hi

my problem was that the "index page" was not "loged in-aware" and always presented the login form. 

one test to do ... after making  the first login go to a page that is "loged in-aware", take the url and open it in another tab, usually it should show that page ... share the session.

i'm thinking that after you've done the first login you've been sent to a "loged in-aware" page, opening another tab and going to the "index page" that it isn't "loged in-aware", doing the second login it overwrites the first session, but session being share between tabs and the first tab being in a "loged in-aware" page/context you continue working but with the new session.

I don't know how much of this applies to your case, it's just something similar that happen to me, and hope it makes sense what I'm trying to say.