Hi Dick,
On 11/ 4/08 02:04 PM, Dick Davies wrote:
> On Tue, Nov 4, 2008 at 9:21 PM, Jan Luehe <Jan.Luehe_at_sun.com> wrote:
>
>> Hi Dick,
>>
>> On 11/ 4/08 12:56 PM, Dick Davies wrote:
>>
>>> I'm seeing some weirdness with Firefox and my Glassfish cluster; I'm
>>> continually being
>>> asked to log in.
>>>
>
>
>>> I noticed in addition
>>> to the JSESSIONID cookie, there's an integer set called
>>> JSESSIONIDVERSION. Can someone
>>> explain how that's used?
>>>
>
>
>> GlassFish in-memory replication relies on HTTP session versioning in order
>> to be able to
>> detect stale sessions, and in order to be able to resume an HTTP session
>> with the version
>> requested by the client (which would be the session's most recent version).
>>
>> Session versioning information is carried via a cookie named
>> JSESSIONIDVERSION.
>>
>
>
> Thanks Jan, that makes a lot of sense.
>
> So to clarify, this is something Glassfish (the appserver) is managing,
> rather than Roller (the webapp), am I right?
Correct. Both the JSESSIONID and JSESSIONIDVERSION cookies
are container-managed.
> It's just it's not always easy to
> tell which of the two needs a tweak for any given bug :)
>
> Does the following sound normal, then?
>
> Bear with me and maybe you'll understand why I was asking if there was
> a session debugger earlier today :)
>
> Once I've logged in, Safari has 2 cookies
>
> JSESSIONID = <the session id>, path = /
> JSESSIONIDVERSION cookie , path = / , contents = /:43
>
> as i click around the webapp, the contents increments: /:44 , /:45 , etc.
> and the path remains as /.
>
From your cookies, it seems that you've deployed Roller at the root
context,
i.e., "/". Can you please confirm?
> But logging in with Firefox 3 and clicking around the app
> seems to create multiple cookies called
> JSESSIONIDVERSION , each with a different path.
>
> For example, I currently see:
>
>
> JSESSIONID = <the session id>, path = / , (only send for encrypted connections)
> JSESSIONIDVERSION cookie , path = / , contents = /:1
> JSESSIONIDVERSION cookie , path = /default/resource/images/ , contents = /:2
> JSESSIONIDVERSION cookie , path = /roller-ui/, contents = /:1
> JSESSIONIDVERSION cookie , path = /roller-ui/styles/ , contents = /:4
> JSESSIONIDVERSION cookie , path = /roller-ui/theme/tan/ , contents = /:5
>
> So Safari seems to (corrrectly?) ignore the path
> but firefox treats the combination of path+cookie name as unique,
> resulting in duplicate jsessionidversion cookies, one per path, each versioned
> independantly (which makes it possible for there to be 2 cookies each
> with a version of /:1)
>
What I don't understand is that you seem to be getting different cookies
depending on what browser you are using. As mentioned above, the cookies
in question are created and managed by the container, so they should not be
affected by the browser in use.
The container uses the webapp's context root as the cookie path, so I'm
not sure
I understand how you could end up with a cookie path equal to
"/default/resource/images/" or "/roller-ui/theme/tan/". It looks like
Firefox 3 is
somehow manipulating your cookie paths, but I don't see how.
What you show as "contents" of the JSESSIONIDVERSION cookies
is a concatenation of context-root and session-version pairings (in your
case, there is only one such pair per cookie). This is to support
cross-context dispatch scenarios, where a request may be dispatched to
several contexts, and may initiate a session in each. In this case,
the contexts will share the same session id, but the session id will
reference a different session in each context. Therefore, the version
info for each of these sessions must be maintained as a separate
context-root/session-version pairing.
In this case, the cookie path would be configured to be equal to "/", so
that
each session may be resumed independently, and the context-root in each
of the pairings will show the associated context's context root.
Give the above, I'm not sure how you could end up with a cookie of this
form:
JSESSIONIDVERSION cookie , path = /roller-ui/, contents = /:1
You may have already mentioned this earlier, but what version of GlassFish
are you using?
Thanks,
Jan
> My hunch is that what I'm seeing is
>
> 1. firefox goes back to /roller-ui/styles and presents a
> jsessionidversion of /:4,
> 2. glassfish is expecting /:5 and invalidates the session
> 3. the user gets to curse at the login screen again
>
>
> Anybody seen anything like this before ??
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>