-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Iain,

On 2/19/2010 1:45 PM, iainmac wrote:
>> 1. When do you set the "userName" attribute in the session?
>> On validation of the user.

Do you mean "identification" or the user (that is, somehow they enter
their username without attempting to authenticate)?

>> 2. When does authentication occur? How? Container-based, or your own?
>> I so also have container based as well as my own.

Uh... you are authenticating twice? Why?

>> 3. When does the session appear to be reset?
>> It's clear whats happenign - just not sure why:
>> 1. From logon screen a new session is created, against that the username and
>> other attributes are stored.
>> 2. After the logn screen does this it then redirects to the actual page I
>> need.
>> 3. This page is made up of a parent frame and 2 sub-frames.
>> 4. The parent frame (the named page that the redirect is to) does that check
>> above i.e. tries to get the Username from the session object-  This works
>> successfully.  This page begins to load.
>> 5. The first sub-frame begins to lad, tries the same check - in MSIE (and in
>> Tomcat 5.0.28 other browers too) we are given the same validated session, so
>> all works fine.  In other browsers with 6.0.24 a new session is given, and
>> so I am again redirected to the logon page! In a loop!  Same this happens
>> with second sub frame.

...and you're sure this only happens with 6.0.24 (and not 6.0.20, etc.)
and only with non-MSIE browsers?

Have you tried a packet-capture to see what the differences in the
requests are from each browser? That may help a lot to see if MSIE
itself is behaving differently.

I would bet that you have, somewhere in your frames, a URL with a
missing ;jsessionid appended to it, though it would only be a problem if
cookies were disabled in the browser or for the webapp. Are either of
these the case?

> As a work around I have simply rewritten my pages not to use frames, all
> works fine.  I do wish new versions would keep default behaviour or make it
> clear the default behaviour has changed.

You /are/ upgrading to a version of Tomcat that is /two/ major versions
beyond what you already had... there are likely to be some changes. Did
you read the changelogs for: 5.0.28 -> 5.0.[latest], 5.0.[latest] ->
5.5.[latest], and 5.5.[latest] -> 6.0.24?

If you think you've uncovered a bug, please write-up the simplest test
case that you can get to work and file it: Tomcat only gets better when
this community takes the initiative to make it so.

> I think its related to the session hijacking mentioned in the other
> reply, but i didn't understand all on the linked page.

Basically, when the user is authenticated, the session is re-created. I
haven't checked, but I would imagine that all the session data from the
old session would be copied into the new session, so you shouldn't
"lose" data.

My bet is on an application bug, given that:
1. You are using frames
2. You are using your own hand-rolled authentication

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuBXfMACgkQ9CaO5/Lv0PA3jQCgm48ClN4SvmfByjBqRv8Ar10E
e8sAoL46S8Tx/NgeK676xgoIhjYMcpGa
=Bi0j
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to