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
