Bruce, That is strange behavior... And you are using the Servlet session class (HttpSession)? I haven't looked into the main Turbine source, but I would imagine it's using the Servlet 2.2 Session Tracking API, in which case there is no way that Session information ever gets displayed in URLs. Even with disabled cookies, all you get on the URL is the session number, since all Session information is local to the server.
Maybe this will help you: if you are using Velocity Templates with Turbine you can configure a default error screen in the TR.prop file: template.error = /Error.vm screen.error=VelocityErrorScreen That way any unhandled exceptions would get passed through VelocityErrorScreen onto the Error template, which could generate a simpler error screen without displaying any stack traces or other information. By the way, I believe VelocityErrorScreen passes a "stackTrace" Velocity variable to Error.vm with the stack trace. So if you wanted to display the error stack you could just reference $stackTrace by default. By the way, are these other services running in the same Turbine instance/webapp? Daniel. ----- Original Message ----- From: "Bruce Altner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 24, 2001 5:13 AM Subject: session variables that appear in url > Greetings: > > One of my requirements is single-sign-on, whereby the user logs in only > once for all services. The username and password are captured at login and > stored in session variables for this purpose. Now some of the services > require the password for authentication, so I pull this from the seesion. > So far so good. But in my testing, usually after some Exception has > occurred, I have occasionally seen the password appear in the URL even > though I never explicitly pass it this way, and never would, of course. > > Since unanticipated exceptions do occur, even in production software, this > is a concern and I'd like to know why this is happening. I suspect it has > something to do with Turbine's capability to automatically stick cookies > into the URL when the browser disables them, which I have not yet studied. > Is there a way to "protect" certain session values from ever being handled > this way? If not, how do others handle the transfer of sensitive > information like this, which must never be exposed, even accidentally? > > Thanks, > Bruce > _________________________________________________________________ > "It's a magical world, Hobbes, ol' buddy...let's go exploring!" ---Calvin > > Phone: 202-651-8553 > Pager Email:[EMAIL PROTECTED] > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
