Martijn,
I get the rationale which is why I have other cookies that are marked
as secure; however, the JSESSIONID cookie has a special use by the JSP
server and is used for associating a user with a session so it should
always be passed unsecured just to keep the user associated with the
proper clustered server and with the proper backend mapping. The more
secure cookies can be used for other uses.
Keith
On Dec 17, 2008, at 12:00 PM, Martijn Brinkers wrote:
The rationale for securing the cookies (ie only send them when a https
connection is used) is that if your cookies are not protected you are
vulnarable to cookie hijacking.
See for example:
http://fscked.org/blog/fully-automated-active-https-cookie-hijacking
Perhaps you can override the cookie service? or create a 'copy' of the
JSESSIONID cookie in your login page but this time unprotected?
Martijn Brinkers
On Wed, 2008-12-17 at 11:42 -0600, Keith Bottner wrote:
I am having a small problem with JSESSIONID cookie having its secure
property set to TRUE when you initially connect. We have a login page
that is displayed first and uses SSL. After login only certain parts
of the web site use SSL. However, since initial connection to the web
server was with SSL and it creates a JSESSIONID cookie for the
initial
connection, it reads the page as secure and therefore sets the secure
bit. This is a problem because the JSESSIONID cookie is then not
passed back in subsequent requests to the server for non SSL pages
which means the user is not tied back to their session appropriately.
Anyone have any ideas on how JSESSIONID can be forced to NOT be
secure
regardless of the Request.isSecure() result?
Thanks in advance,
Keith
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
