Re: JSESSIONID cookie, secure is set, how to not set
I don't know how to do it within Tapestry, but generally you can use a
filter to make sure that jsessionid is never set as a secure cookie. I
dug up some old code that does that, I think it works:
public class TomcatUnifiedSessionFilter implements Filter {
public void destroy() {
// nothing to do here
}
public void doFilter(final ServletRequest request, final
ServletResponse response, final FilterChain chain)
throws IOException, ServletException {
/*
* Tomcat tracks the session using the JSESSIONID. When the session is
* created as a consequence of a request of a secure page, however, the
* "secure" attribute of the cookie is set to true. That prevents the
* session to be consecutively tracked on non-secure pages. We would
* like a unified approach, though.
*/
final HttpServletRequest httpRequest = (HttpServletRequest) request;
final HttpServletResponse httpResponse = (HttpServletResponse) response;
// TODO: some more explanation
final HttpSession session = httpRequest.getSession(false);
if (session != null) {
final Cookie sessionCookie = new Cookie("JSESSIONID",
session.getId());
sessionCookie.setMaxAge(-1);
sessionCookie.setSecure(false);
sessionCookie.setPath(httpRequest.getContextPath());
httpResponse.addCookie(sessionCookie);
}
chain.doFilter(request, response);
}
public void init(final FilterConfig config) throws ServletException {
// nothing to do here
}
On Wed, Dec 17, 2008 at 8:51 PM, Keith Bottner wrote:
> 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
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: JSESSIONID cookie, secure is set, how to not set
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
Re: JSESSIONID cookie, secure is set, how to not set
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
JSESSIONID cookie, secure is set, how to not set
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
