You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Bruce Altner <ba...@hq.nasa.gov> on 2001/11/24 11:13:53 UTC

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:8273479@skytel.com




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: session variables that appear in url

Posted by Gareth Coltman <ga...@majorband.co.uk>.
Not to my knowledge.

> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
> [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
> Sent: Monday, November 26, 2001 16:59
> To: Turbine Users List
> Subject: Re: session variables that appear in url
> 
> 
> "Gareth Coltman" <ga...@majorband.co.uk> writes:
> 
> > Think I know the answer to this one.
> >
> > This problem is due to Turbine rewriting the query data into the
> > path, when the user starts a new session. Turbine tries to ensure
> > session tracking is working by doing a redirect after the users
> > first request. If an exception occurs in this redirected request,
> > the path will be displayed showing any query data, even if it was
> > sumbitted POST. There is some stuff in the archive about this
> > problem.
> >
> > We removed the redirect from our Turbine code (Turbine.java) and
> > this problem seems to have gone away.
> 
> Was this redirect removed from CVS HEAD as well?
> 
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: session variables that appear in url

Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Gareth Coltman" <ga...@majorband.co.uk> writes:

> Think I know the answer to this one.
>
> This problem is due to Turbine rewriting the query data into the
> path, when the user starts a new session. Turbine tries to ensure
> session tracking is working by doing a redirect after the users
> first request. If an exception occurs in this redirected request,
> the path will be displayed showing any query data, even if it was
> sumbitted POST. There is some stuff in the archive about this
> problem.
>
> We removed the redirect from our Turbine code (Turbine.java) and
> this problem seems to have gone away.

Was this redirect removed from CVS HEAD as well?

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: session variables that appear in url

Posted by Gareth Coltman <ga...@majorband.co.uk>.
Think I know the answer to this one.

This problem is due to Turbine rewriting the query data into the path, when the user starts a new session. Turbine tries to ensure
session tracking is working by doing a redirect after the users first request. If an exception occurs in this redirected request,
the path will be displayed showing any query data, even if it was sumbitted POST. There is some stuff in the archive about this
problem.

We removed the redirect from our Turbine code (Turbine.java) and this problem seems to have gone away.

Gareth


> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
> [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
> Sent: Monday, November 26, 2001 06:51
> To: Turbine Users List
> Subject: Re: session variables that appear in url
>
>
> Bruce Altner <ba...@hq.nasa.gov> writes:
>
> > I will be careful to note the next time it happens and record all
> > the details.  It is quite disconcerting to see passwords on display
> > like that.
>
> Definitely.  Steps to reproduce would be appreciated.
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: session variables that appear in url

Posted by Daniel Rall <dl...@finemaltcoding.com>.
Bruce Altner <ba...@hq.nasa.gov> writes:

> I will be careful to note the next time it happens and record all
> the details.  It is quite disconcerting to see passwords on display
> like that.

Definitely.  Steps to reproduce would be appreciated.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: session variables that appear in url

Posted by Bruce Altner <ba...@hq.nasa.gov>.
Daniel:

Yes, I am using HttpSession. Also, I do use the settings in TR.prop that you
suggested although these days I am redirecting to specific error pages whenever
I catch an Exception. And yes, everything is running in the same webapp.

I will be careful to note the next time it happens and record all the details.
It is quite disconcerting to see passwords on display like that.

Bruce

At 08:02 PM 11/25/2001 -0500, you wrote:
>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" <ba...@hq.nasa.gov>
>To: <tu...@jakarta.apache.org>
>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:8273479@skytel.com
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
> > For additional commands, e-mail:
><ma...@jakarta.apache.org>
> >
> >
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

_________________________________________________________________
"It's a magical world, Hobbes, ol' buddy...let's go exploring!" ---Calvin

Phone: 202-651-8553
Pager Email:8273479@skytel.com




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: session variables that appear in url

Posted by "Daniel B. Ramagem" <da...@ssaihq.com>.
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" <ba...@hq.nasa.gov>
To: <tu...@jakarta.apache.org>
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:8273479@skytel.com
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>