You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Keith Bottner <kb...@gmail.com> on 2008/12/17 18:42:54 UTC
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: JSESSIONID cookie, secure is set, how to not set
Posted by Lutz Hühnken <lh...@googlemail.com>.
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 <kb...@gmail.com> 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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: JSESSIONID cookie, secure is set, how to not set
Posted by Keith Bottner <kb...@gmail.com>.
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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: JSESSIONID cookie, secure is set, how to not set
Posted by Martijn Brinkers <ma...@gmail.com>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org