Re: Custom session tracking method?

[Sandy McArthur]

The first request the legacy app makes is to /login which it uses your 
normal Basic authentication which is nice because I can use a standard 
Realm. In the response to /login is a session number the client should 
use along with some data about the user's account. Unfortunately the 
session number must fit in a 4 byte integer in the app. :( After that 
the session is passed around via the session-num query param.

Sandy McArthur

On Apr 7, 2004, at 11:33 AM, Mike Curwen wrote:

How does your legacy client *first* get the session id ?

the client passes session ids as a query
parameter named 'session-num'


From whence does the "session-num" query parameter come?  Does the
legacy client create a random number and use it?  Do the cgi scripts
pass it back on a login of some sort, and then from that point, the
legacy app appends it to any further queries?


-----Original Message-----
From: Sandy McArthur [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 07, 2004 10:21 AM
To: Tomcat Users List
Subject: Re: Custom session tracking method?

Since you're rewriting your CGI scripts as servlets, why not modify
them
to not expect the session-num parameter, and instead get
the session ID
via normal java code (request.getSession().getId())?  It's simpler,
standard, less code for you to write and test...
My problem is the client, which is a desktop app, doesn't support
cookies and uses hardcoded URIs for the cgi's. The app is
what uses the
query parameter session-num for session tracking, otherwise I would
prefer to use the normal session tracking semantics.
Sandy

For those who didn't see the original post on tomcat-dev:

On Apr 7, 2004, at 8:54 AM, Shapira, Yoav wrote:

Hi,
The reason your approach feels ugly and fragile to you is
because it
IS
;)  Session-tracking is mandated by a couple of specs
(J2EE, Servlet),
and tomcat implements it per the spec.  If you do something
different,
you will very likely have misbehaving 3rd party libraries
that rely on
proper session tracking behavior.

Since you're rewriting your CGI scripts as servlets, why not modify
them
to not expect the session-num parameter, and instead get
the session ID
via normal java code (request.getSession().getId())?  It's simpler,
standard, less code for you to write and test...
Please continue this discussion on the tomcat-user list, not
tomcat-dev.
Yoav Shapira
Millennium Research Informatics

-----Original Message-----
From: Sandy McArthur [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 06, 2004 5:05 PM
To: [EMAIL PROTECTED]
Subject: Custom session tracking method?
Hi all,

Is there a way to implement custom session tracking at the
container
level?

I'm trying to figure out how to implement a custom session
tracking
method. I have a legacy client that interacts with a set of cgi
scripts and I'd like to port those scripts to servlets.
I'm running
into a problem because the client passes session ids as a query
parameter named 'session-num' (e.g.:
/update?session-num=TOKEN). The
client does not support cookies and there is no way to
tell it use a
JSESSIONID encoded in the path.

I've followed the code as best as I can starting at
org.apache.coyote.tomcat5.CoyoteAdapter parses the JSESSIONID from
the request/cookies to where the
org.apache.catalina.Manager fetches
the org.apache.catalina.Session and I don't see anyway to directly
override the session tracking behavior.
The best idea I currently have is to use a Valve and a
custom Manager
and hope none of the Manager.{create,find}Session() methods are
called before my Valve can parse the request and stuff the
"session-num" in a ThreadLocal that Manager can use when
returning a
Session.

That feels ugly and fragile to me. Does anyone have a better
solution?
Sandy McArthur


This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged.  This e-mail is intended
only for the
individual(s) to whom it is addressed, and may not be
saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an)
intended recipient, please immediately delete this e-mail from your
computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]