Short of a RIA, there are plenty of ways to deal with this issue and
it's not necessarily IE specific.
The typical way I suppose is that in step 4, how's the user even able
to login as a different user? The login option shouldn't be available
- only logout. But if it is and/or user sends a login request anyway,
you are still firmly in control of the server side: if an existing
session exists, you should invalidate it first ("logout") before
allowing the user to login again.
Kalle
On Wed, Sep 29, 2010 at 9:52 AM, Les Hazlewood <[email protected]> wrote:
> Hello,
>
> This is an IE issue, not a Shiro issue. IE's default setting is that
> ctrl + t will share the same session between tabs. In IE 8, you can
> choose File > New Session and this won't happen; the IE team added
> this new feature specifically to address the issue you're seeing. The
> browser, not server-side Shiro, determines how session cookies are
> maintained.
>
> The only way around this that I know of is solved by RIA frameworks -
> where the framework itself maintains the session ID internally and a
> browser cookie is never added. For example GWT applications do this -
> GWT maintains a session ID internally and accompanies it along with
> every GWT request into the server.
>
> If anyone has any other ideas as solutions, I'd love to hear them.
> Otherwise the RIA framework approach is the only one that I'm aware
> of.
>
> Cheers,
>
> --
> Les Hazlewood
> Founder, Katasoft, Inc.
> Application Security Products & Professional Apache Shiro Support and
> Training:
> http://www.katasoft.com
>
>> JSESSIONID and hence does not create a new session ID. This is easily
>> reproducible if you do the following:
>>
>> step1: At the app launch, http://<login_url> (e.g. UUID sessionid is created
>> - say a71a904c)
>> step2: User A login is successful (binds userA -> a71a904c sessionid)
>> step3: cntrl+t; launch the app, http://<login_url> (existing JSESSION cookie
>> found by IE). This is because IE opens new tab under same process.
>>
>> step4: User B login is successful (binds userB -> a71a904c sessionid)
>>
>> *** Now UserB (last logged in user) takes over the session owned by userA.
>> Any saves etc done by UserA are still saved (owned) as user UserB ***
>>
>> Is there a way to prevent this ? Easiest way would be to generate new
>> session.
>>
>> --
>> View this message in context:
>> http://shiro-user.582556.n2.nabble.com/User-session-take-over-in-IE-cntrl-t-scenario-tp5583901p5583901.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
