Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: 24.24.2.57 is neither permitted nor
 denied by domain of dns4@cornell.edu)
Message-ID: <4683A8B9.1070703@cornell.edu>
Date: Thu, 28 Jun 2007 08:25:29 -0400
From: David Smith <dns4@cornell.edu>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: OT: Sessions
References: <10401644.1183004858518.JavaMail.root@fed1wml09.mgt.cox.net>
In-Reply-To: <10401644.1183004858518.JavaMail.root@fed1wml09.mgt.cox.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

The problem is you are allowing two users to login to what tomcat sees=20
as the same browser window.  When you do Ctrl-N from IE or just anything =

method of creating a new window from Firefox, it's on the same process=20
and has access to all the same cookies as the first one.  To handle the=20
issue properly requires you actually check to see if there is a=20
pre-existing session before allowing the user to login.  Force the first =

user to log-out before allowing another to login from the same browser=20
window (or any of it's session sharing siblings).  Alternatively you=20
could automatically logout the first user when the second one log's in=20
since it's obvious the first user is no longer present.

In the login page, just do a check:

<c:choose>
  <c:when test=3D"${not empty userName}">
    <!-- Ship back an error -->
  </c:when>
  <c:otherwise>
    <!-- Display the login page -->
  </c:otherwise>
</c:choose>

You'll be much happier if your app design allows for only one user from=20
any given client browser process regardless of multiple windows.  It=20
also enforces the security you appear to be after with fine grained=20
audit logs.

--David

vnug@cox.net wrote:
> Hi:
>
> Thanks David, Chris and Martin for the responses. I appreciate them. Ma=
y be I didn't explain the situation properly in my posting. I will try to=
 explain better -
>
> The application has pretty decent authentication mechanism that differe=
ntiates between users, roles and permissions etc. What the application ne=
ed to maintain is user object information specifically - name, role, dept=
 - to be used across other pages of the application. Since we are using s=
ession as datum -  after 2nd user logs in ... the 1st user object is over=
written with 2nd user information. This creates problems specifically whi=
le logging out. In the application we are making sure that only one user =
login is allowed per user. This also complicates when we are attempting t=
o create audit log of the user operations. Even though an operation is pe=
rformed by the 1st user the audit log registers it as the operation perfo=
rmed by 2nd user. This messes up the whole point of creating audit logs. =
 Also, for the question of Chris - there could be a need for two differen=
t users with different roles could try to login and that is when we are h=
aving this problem. Thanks again for the fe
>  edback.
>
> regards,
> vasu
>
>
> ---- Christopher Schultz <chris@christopherschultz.net> wrote:=20
>  =20
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Vasu,
>>
>> vnug@cox.net wrote:
>>    =20
>>> Since we are using Session Attributes to keep track of User
>>> Information - this gets mangled when we try to login to application
>>> from the same browser (in FireFox) and Ctrl-N from IE (in other words=

>>> the person who gets logged in will overwrite the current user's
>>> attribute thus losing first user information).
>>>      =20
>> Just to be sure I understand:
>>
>> You have an application that uses sessions.
>>
>> When the user logs-in in one window, then opens another window and
>> logs-in again, the first user's session appears to go away, and both
>> windows now point to the new login?
>>
>> If that's what you are describing, then it is expected behavior if you=

>> are using cookies for session management.
>>
>> When cookies are used, the browser sends a cookie with each request. T=
he
>> cookie chosen by the browser is based on the hostname and path being
>> used for the request (say, www.mysite.com/mypath).
>>
>> When you login from the second window, your browser deletes the ole
>> JSESSIONID cookie and replaces it with the new one (from the new login=
).
>> Both windows will send the same cookie from then on, essentially
>> cutting-off the first user.
>>
>>    =20
>>> So, I am wondering whether you all have any recommendations/inputs to=

>>> avoid this scenario. Thanks in advance. I did check the google and
>>> other search tools, but could not locate anything useful.
>>>      =20
>> One way to get around this is to turn off the use of cookies for sessi=
on
>> tracking. Search the web or the archives of this list (or read the
>> Tomcat docs) to see how to do this. REMEMBER that if you aren't using
>> cookies, /every single URL to emit must be sent through
>> HttpServletRequest.encodeURL/, otherwise clicking on a (non-encoded)
>> link will appear to lose the session.
>>
>> My last question would be: why do you need to have multiple windows wi=
th
>> separate logins?
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.7 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFGgmSX9CaO5/Lv0PARAlh+AKCTibYLgZR9+T6DjXDNrEwMAWawpACdHfLi
>> RNrnxDmhylsMfU/bbqWYCRo=3D
>> =3Dmlah
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>    =20
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>  =20


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org