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]
