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

Reply via email to