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. On Monday, February 10, 2014 4:45:36 PM UTC+1, aditi wrote: > > 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? > > On Monday, February 10, 2014 7:57:08 PM UTC+5:30, Thomas Broyer wrote: >> >> >> >> 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-sessionfor a >> discussion on the subject >> > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
