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:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 10:21 AM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
- - Scott Ahten Interactive Architect - - - - D E V O T I O N devotion media - - - - http://www.devotionmedia.com/ - - - - email: [EMAIL PROTECTED] office: 407.677.8514 cell: 321.276.0291 - - - - Secret headquarters: 4440 Metric Drive Suite E Winter Park, Florida 32792 - -
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
