Thank you for the clarification Mark. > Depending on where the session is created, you might be able to use a > filter to wrap your response and modify the secure attribute of any > cookies as they are added to the response.
I am sorry to bother you but I don't see how I could wrap the class o.a.c.connector.Response whose method addCookieInternal(cookie) is called by o.a.c.connector.Request.doGetSession(boolean) to create the JSESSIONID cookie. As o.a.c.connector.Response is a class, I cannot use j.l.reflect.Proxy that only supports interfaces. Do you have in mind AOP, subclassing o.a.c.connector.Response or another approach ? If all this is to complex, I will fall back to another approach that is to do pattern matching (10.*) on request.remoteAddr to flag RequestFacade.secure=true if the requests come from my secured network area. This will let request.secure=false if request.scheme=http and thus have non-secure JSESSIONID cookies. I tested with a valve called SecuredRemoteAddressesValve (1) that I precede of RemoteIpValve (2) to process the x-forwarded-for header to find the real remoteAddr and this works fine. Thanks very much for your help, Cyrille (1) http://xebia-france.googlecode.com/svn/tomcat/xebia-tomcat-extras/tags/xebia-tomcat-extras-0.5/src/main/java/org/apache/catalina/connector/SecuredRemoteAddressesValve.java (2) http://xebia-france.googlecode.com/svn/tomcat/xebia-tomcat-extras/tags/xebia-tomcat-extras-0.5/src/main/java/org/apache/catalina/connector/RemoteIpValve.java On Tue, Jun 23, 2009 at 12:40 AM, Mark Thomas<ma...@apache.org> wrote: > Cyrille Le Clerc wrote: >> Thanks very much for the time you spend on my problem Christopher. >> >> I use two connectors : one with secure=true and scheme=http ; another >> with secured=true, scheme=https. >> >>> What is the requirement that scheme=http? You can actually use a >>> (non-secure) HTTP connector and still set scheme=https. Do you have some >>> portion of your application that relies on request.getScheme() returning >>> "HTTP"? >> >> My application only checks request.secure=true. >> >> I would like Tomcat to create non-secure JSESSIONID cookies (ie >> non-ssl cookies) on the connector with secure=true and scheme=http. >> >> Today, if request.secure=true and request.scheme=http then Tomcat >> creates a secure JSESSIONID cookie that is ignored by http clients >> like Apache Http Client because these clients associates secure >> cookies with HTTPS. >> >> The modification would be that Tomcat to rely on request.scheme=https >> to create secure JSESSIONID cookies instead of relying on >> request.secure=true as it is done today. It would require one line of >> change on org.apache.catalina.connector.Request: >> >> protected void configureSessionCookie(Cookie cookie) { >> ... >> + if ("https".equals(getScheme())) { >> - if (isSecure()) { >> cookie.setSecure(true); >> } >> } >> >> >>> If HTTPS is not being used /at all/, then why do you want to claim that >>> it is secure? If you aren't using SSL, then not having SSL cookies >>> shouldn't be a problem, right? >> >> My problem is to have SSL cookies for HTTP requests : if >> request.scheme=http and request.secure=true, then Tomcat creates a >> secure JSESSIONID cookie (ie an SSL cookie) when I would like >> non-secured (ie non-secured) cookies. > > The Tomcat code will not be changed to behave in this way. > > The secure attribute is intended for use in architectures like: > > client <--https--> httpd <--http/ajp--> tomcat > > Depending on where the session is created, you might be able to use a > filter to wrap your response and modify the secure attribute of any > cookies as they are added to the response. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org