Good call Kalle - that didn't come to mind as I was thinking almost
entirely about the browser, not the server side. But you don't need
to force a logout either (although that is one approach, depending on
what you may want).
Another approach is to check to see if you even want to perform the
login based on their current authentication state. For example:
if ( subject.isAuthenticated() ) {
//they're already logged in, so redirect to the
//home page and don't process the login
} else {
subject.login(myAuthenticationToken);
}
This is up to the shiro end-user - not something that Shiro will
enforce out of the box (that is, if you want to call login 10 times in
a session, that's up to you - Shiro won't prevent it). But you can
use the isAuthenticated() method (or other criteria) to help determine
if you want to actually execute the login or not.
Now if you actually do want two different sessions in two different
tabs, you'll still need to rely on browser features ('New Session',
etc) or the RIA approach to make that work (unless I'm missing another
technique).
--
Les Hazlewood
Founder, Katasoft, Inc.
Application Security Products & Professional Apache Shiro Support and Training:
http://www.katasoft.com
> 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.
>>>
>>
>
