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-session for > 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.
