tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sidney-Woollett <joh...@wardbrook.com>
Subject Re: http->https url rewrite bug TC 5.0.28?
Date Mon, 15 Nov 2004 17:46:26 GMT
Tomcat still seems broken to me because it does in fact "share" the 
session from a non-secure connection to a secure connection when cookies 
are enabled, but not when they are not.

But you've given me some inkling as to what is going on.

I can't believe that there isn't a standard solution for dealing with 
this issue.

ie, non-ssl when adding things to your basket, switch to SSL going 
through the checkout stages, then back to non-ssl after completing the 
order.

Thanks for the extra info.

John

Scott Ahten wrote:

> To clarify Yoav's response, this is not a bug but by design.
> 
> Tomcat does not allow session data to be shared between secure and  
> non-secure pages. This is to prevent someone from gaining access to  
> session data that was submitted via a secure page by using a non-SSL  
> URL and the user's session id, observed during the initial unencrypted  
> connection.
> 
> You will need to either collect all necessary information via SSL or  
> persist data from the non-secure session (database, serialization,  
> etc.) for retrieval by the secure session when you make the switch.
> 
> - Scott
> 
> On Nov 15, 2004, at 10:24 AM, Shapira, Yoav wrote:
> 
>>
>> Hi,
>> Not a bug.  You can't share a session that way, whether using cookies  or
>> URL-rewriting.
>>
>> Yoav Shapira http://www.yoavshapira.com
>>
>>
>>> -----Original Message-----
>>> From: John Sidney-Woollett [mailto:johnsw@wardbrook.com]
>>> Sent: Monday, November 15, 2004 10:21 AM
>>> To: tomcat-user@jakarta.apache.org
>>> Subject: http->https url rewrite bug TC 5.0.28?
>>>
>>> I'm not sure if this is a bug or a misunderstaning on my part - and
>>
>> I've
>>
>>> been searching the archives and googling for most of the day without
>>> success...
>>>
>>> I've got a problem where URL rewriting is failing to correctly encode
>>> the URL when switching from an insecure (non-ssl) connection to a
>>
>> secure
>>
>>> ssl connection FOR THE SAME DOMAIN and where the session already  exists
>>> for the insecure connection and COOKIES ARE DISABLED in the browser. I
>>> can reproduce this behaviour with different browsers.
>>>
>>> An "action" servlet receives the non-ssl request and redirects to
>>> another secure "action" servlet. The call for the redirect should
>>
>> encode
>>
>>> the URL as follows in the first servlet's service(request, response)
>>> method:
>>>
>>> [snip]
>>> if (gotoCheckout)
>>> {
>>>     //goto the checkout
>>>     //this generates the URL
>>>     //https://www.mytestsite.com/CheckoutAction?action=start
>>>     String url = CheckoutAction.getCheckoutActionStartURL(request);
>>>
>>>     //make sure the JSESSIONID is appended for non-cookie browsers
>>>     url = response.encodeRedirectURL(url);
>>>
>>>     response.sendRedirect(url);
>>>     return;
>>> }
>>> [snip]
>>>
>>> Looking at the headers, you can see that the JSESSIONID is not  appended
>>> to the redirect URL when the protocol switches from http to https:
>>>
>>> REQUEST
>>> =======
>>> POST
>>> http://www.mytestsite.com/BasketAction; jsessionid=9E490ADF8FB268E3F6BC5
>>
>> FA2F
>>
>>> D61E8CF
>>> HTTP/1.1
>>> Host: www.mytestsite.com
>>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
>>> Gecko/20030728 Mozilla Firebird/0.6.1
>>> Accept:
>>> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/ pla
>>
>> in;q
>>
>>> =0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
>>> Accept-Language: en-us,en;q=0.5
>>> Accept-Encoding: gzip,deflate
>>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>> Keep-Alive: 300
>>> Proxy-Connection: keep-alive
>>> Referer:
>>> http://www.mytestsite.com/basket; jsessionid=9E490ADF8FB268E3F6BC5FA2FD6
>>
>> 1E8C
>>
>>> F
>>> Content-Type: application/x-www-form-urlencoded
>>> Content-Length: 66
>>> ret=%2Fimage%2F6503740500223&action=upd&butaction=checkout&qty_0=1
>>>
>>> RESPONSE
>>> ========
>>> HTTP/1.x 302 Moved Temporarily
>>> Date: Mon, 15 Nov 2004 13:38:23 GMT
>>> Server: Apache/1.3.29
>>> Location: https://www.mytestsite.com/CheckoutAction?action=start
>>> Content-Length: 0
>>> Content-Type: text/plain
>>> Connection: close
>>>
>>>
>>> Setup
>>>
>>> Apache 1.3.29 + mod_ssl + mod_jk + tomcat 5.0.28 (unix)
>>>
>>> Apache is configured with two virtual directives; one for port 80 and
>>> one for post 443 and the requests are forwarded by mod_jk to tomcat
>>> which has the following in its server.xml config:
>>>
>>> [snip]
>>> <Host name="www.mytestsite.com" appBase="/ef02/tc/www.mytestsite.com">
>>>  <Context path="" docBase="ROOT" debug="0" reloadable="false">
>>>   <ResourceLink name="jdbc/D1DB" global="jdbc/D1DB"
>>> type="javax.sql.DataSource"/>
>>>  </Context>
>>> </Host>
>>> [snip]
>>>
>>> Tomcat possibly nevers "sees" that the request is secure because the
>>
>> SSL
>>
>>> part of the transaction is handled by mod_SSL, and I don't know if  this
>>> has a bearing on the issue?
>>>
>>> My question, should the JSESSIONID be appended in the encoded redirect
>>
>> -
>>
>>> I think so?
>>>
>>> And if it should, am I doing something wrong. Or is there a bug?
>>>
>>> If there is a bug, should I manually append the ";jsessionid=xxxxxxx"
>>
>> to
>>
>>> the URL to workaround the problem.
>>>
>>> Can anyone shed any light on this?
>>>
>>> Many thanks
>>>
>>> John Sidney-Woollett
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>>
>>
>> This e-mail, including any attachments, is a confidential business  
>> communication, and may contain information that is confidential,  
>> proprietary and/or privileged.  This e-mail is intended only for the  
>> individual(s) to whom it is addressed, and may not be saved, copied,  
>> printed, disclosed or used by anyone else.  If you are not the(an)  
>> intended recipient, please immediately delete this e-mail from your  
>> computer system and notify the sender.  Thank you.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
>>
>>
> - -
> Scott Ahten
> Interactive Architect
> - - - -
> D  E  V  O  T  I  O  N
> devotion media
> - - - -
> http://www.devotionmedia.com/
> - - - -
> email: scott@devotionmedia.com
> office: 407.677.8514
> cell: 321.276.0291
> - - - -
> Secret headquarters:
> 4440 Metric Drive
> Suite E
> Winter Park, Florida 32792
> - -
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message