Hmm... Ok, I see. I will try googling. Thanks.
Well, the reason for different sessions in different tabs is this
scenario: Using a special link, a user can embed (a part of) our
application into his website. If a user browses to his website and
opens the same website in a different tab (which might happen
frequently, maybe because all links on the page open in new tabs),
problems will arise. As a stand-alone application, I agree, it doesn't
really make sense to have different session id's for the same user in
different tabs.
Anyway, thanks for your help, I'll look into session URLs and if that
doesn't help, --- well, I'm sure to find something else :).
Thanks,
Philipp
On 26 Okt., 14:00, Paul Robinson <ukcue...@gmail.com> wrote:
> I am saying that you need different command line options in FF to make
> it work with separate profiles, and that that would let you have
> different cookies in each profile.
>
> Your session information has to be stored in cookies or in the URL. Each
> has their own pros and cons, but all tabs will share cookies whereas
> each tab can (obviously) have different URLs. Google something like
> "session url" to see if you really want to do that.
>
> I guess the real question is why you want to do this in the first place?
> As a developer, it's good to be logged in with different users at once
> for testing stuff out, but what's the use case for the end user to be
> able to do it?
>
> An easier way to tell client's that want this is to tell them to log in
> with two browsers - like FF and Chrome (or whatever).
>
> Paul
>
> philipp.bouil...@gmail.com wrote:
> > ?
>
> > Thanks, Paul, but I fear I don't (quite) understand.
> > Are you saying that I have to start FF with command line options in
> > order to be able to create different session IDs for different tabs?
> > Even if that should be so, I can hardly communicate this information
> > to all our clients and ask them to start their FF with those options
> > (let alone those clients that are using different browsers, like IE 8
> > for example).
>
> > Isn't there a way of getting different session IDs for different tabs?
> > I have googled some more and found a hint on customizing the apache
> > tomcat session manager... Should I look more deeply into that topic?
> > Sounds a little daunting...
> > Thanks,
> > Philipp
>
> > On 26 Okt., 12:27, Paul Robinson <ukcue...@gmail.com> wrote:
>
> >> The cookies stored by firefox are shared across the tabs. If you want to
> >> be able to log in using separate users in firefox, then you can do that
> >> using separate firefox profiles.
>
> >> Try
>
> >> firefox -ProfileManager
>
> >> the create a new profile or select the profile to run from whatever
> >> profiles you may already have. If you already have firefox running, use
>
> >> firefox -ProfileManager -no-remote
>
> >> to start firefox in a separate process.
>
> >> Paul
>
> >> philipp.bouil...@gmail.com wrote:
>
> >>> Hi,
>
> >>> maybe I get my basics wrong, but I am currently a bit confused, maybe
> >>> you could help me understand what goes wrong here:
>
> >>> I am writing a GWT application where a user has to authenticate
> >>> himself to a database. Upon successful authentication, I create a new
> >>> HttpSession like so:
>
> >>> private final HttpSession startNewSession() {
> >>> HttpSession session = getThreadLocalRequest().getSession();
> >>> if(session != null) {
> >>> return session;
> >>> }
> >>> return getThreadLocalRequest().getSession(true);
> >>> }
>
> >>> which -- as you can see -- does _not_ create a new session, if a
> >>> session already exists.
>
> >>> And that may be the problem: If I log on to my application using two
> >>> different tabs in Firefox (for example), I get _the same_ session...
> >>> Is there any way of forcing the creation of a new session if I log on?
> >>> Am I completely wrong by even needing to do that??
> >>> If the user logs on using two different tabs, I would really like to
> >>> have two completely different sessions, but it seems that
> >>> "getThreadLocalRequest" only allows for _one_ session in this case
> >>> (being thread local... :)).
>
> >>> So, the only way around this problem I see right now, is to modify
> >>> (extend) RemoteServiceServlet and handle the HttpServletRequest(s) and
> >>> HttpServletResponse(s) on my own -- if that is possible... Any ideas?
>
> >>> Thanks for any pointers!
> >>> Philipp
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
