RES: RES: [java] RE: http->https url rewrite bug TC 5.0.28?
Thanks a lot, Steven... As you guess, in our case we don't have important security requirements (just personalized contents) most of time and the hardware isn't that good...but we don't fell confortable to accept http login. One more point in order to implement you suggestion: ".. and automatically logs the user in to the non-secure site without prompting." Could you email a snippet for that? The cookie stuff and "interceptor" will not be a problem - but I couldn't find out how to get the credential from the https sesssion to auto-authenticate the user the next time. Thanks in advance... Paulo -Mensagem original- De: Steven J.Owens [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 15 de novembro de 2004 23:39 Para: Tomcat Users List Assunto: Re: RES: [java] RE: http->https url rewrite bug TC 5.0.28? On Mon, Nov 15, 2004 at 05:13:21PM -0300, Paulo Alvim wrote: > I have a similar problem: I'd like to use https only with the > login.jsp page and come back to http after that. Could you explain > why it isn't possible? It's not possible because it's not _proper_ from a security perspective, so they built tomcat to not enable it. I can sorta understand why people want to do it, myself, but you should understand that it's not secure, and be very much aware of the risks you're taking. Still, I can understand some of the motivation behind the request, and I think there's a solution. The key is to realize you're trying to solve the wrong problem. See my explanation at the end for what the right problem is, and how to solve it. To illustrate this properly, imagine that your account has two usernames and two passwords that you can use to access it, the permanent username/password and a temporary username/password. When you login, you first have to send the permanent username and first password over the net. At that point, the server then sets your temporary username and second password to some random value, temporarily, and then sends those back to you. The temporary username/password will last until your user session times out, or until you explicitly log out. Your browser then sends a copy of that temporary username and temporary password along with _every_ _single_ _request_ to the server. Just because you make sure the first communication, where you sent the permanent username/password, is secure, doesn't keep somebody from sniffing the temporary username and password and using those to do all sorts of damage to your account during that window of opportunity. To bring this back to reality, the JSESSIONID cookie is the temporary username/password. This explains why it is not secure to use the same session for both HTTP and HTTPS connections. Thinking about it, I can certainly see why people would want some happy medium between the two. SSL consumes resources* and often you're not worried about securing the entire series of user interactions, just a critical subset. For example, you don't need to SSL-protect the user browsing your catalog, but you do need to SSL-protect the payment authorization. (* Last I heard, the SSL server takes up about 40% extra resources, though that info is years old and may be way out of date.) However, the important point is _not_ that you want to share the session data across secure and unsecure apps, but that you want to avoid making the user log in twice. Here's how I'd approach this. You need two distinct sets of security credentials, "serious" and "trivial". The serious credential is necessary for the SSL-protected portion, the trivial credential is necessary for the non-SSL portion. Then, when the user logs in via SSL, it also creates a trivial security credential, and sets that on a _different_ cookie than JSESSIONID. It's been ages since I've worked with cookies, but you can mark a cookie as "Secure", meaning it only gets sent back to the secure server, or not. The tomcat SSL-created JSESSIONID is set secure, for example. Here's what one looks like: Set-Cookie: JSESSIONID=202E506FAD4A9ADB5F062DB3A3310E89; Path=/xyzzy; Secure This is further documented at: http://www.ietf.org/rfc/rfc2109.txt However, you can also set a second cookie, _without_ the secure option, from the SSL response. The browser will then include that cookie value in further requests to the non-secure site at the same domain. You would have to customize the non-secure site's security so that it checks for this cookie and automatically logs the user in to the non-secure site without prompting. One thing you'll have to watch out for is the timeout of the SSL session, since it might get left alone for many hours. You have two choices there: 1) either include an SSL-protected icon on every page, which will keep
Re: RES: [java] RE: http->https url rewrite bug TC 5.0.28?
On Mon, Nov 15, 2004 at 05:13:21PM -0300, Paulo Alvim wrote: > I have a similar problem: I'd like to use https only with the > login.jsp page and come back to http after that. Could you explain > why it isn't possible? It's not possible because it's not _proper_ from a security perspective, so they built tomcat to not enable it. I can sorta understand why people want to do it, myself, but you should understand that it's not secure, and be very much aware of the risks you're taking. Still, I can understand some of the motivation behind the request, and I think there's a solution. The key is to realize you're trying to solve the wrong problem. See my explanation at the end for what the right problem is, and how to solve it. To illustrate this properly, imagine that your account has two usernames and two passwords that you can use to access it, the permanent username/password and a temporary username/password. When you login, you first have to send the permanent username and first password over the net. At that point, the server then sets your temporary username and second password to some random value, temporarily, and then sends those back to you. The temporary username/password will last until your user session times out, or until you explicitly log out. Your browser then sends a copy of that temporary username and temporary password along with _every_ _single_ _request_ to the server. Just because you make sure the first communication, where you sent the permanent username/password, is secure, doesn't keep somebody from sniffing the temporary username and password and using those to do all sorts of damage to your account during that window of opportunity. To bring this back to reality, the JSESSIONID cookie is the temporary username/password. This explains why it is not secure to use the same session for both HTTP and HTTPS connections. Thinking about it, I can certainly see why people would want some happy medium between the two. SSL consumes resources* and often you're not worried about securing the entire series of user interactions, just a critical subset. For example, you don't need to SSL-protect the user browsing your catalog, but you do need to SSL-protect the payment authorization. (* Last I heard, the SSL server takes up about 40% extra resources, though that info is years old and may be way out of date.) However, the important point is _not_ that you want to share the session data across secure and unsecure apps, but that you want to avoid making the user log in twice. Here's how I'd approach this. You need two distinct sets of security credentials, "serious" and "trivial". The serious credential is necessary for the SSL-protected portion, the trivial credential is necessary for the non-SSL portion. Then, when the user logs in via SSL, it also creates a trivial security credential, and sets that on a _different_ cookie than JSESSIONID. It's been ages since I've worked with cookies, but you can mark a cookie as "Secure", meaning it only gets sent back to the secure server, or not. The tomcat SSL-created JSESSIONID is set secure, for example. Here's what one looks like: Set-Cookie: JSESSIONID=202E506FAD4A9ADB5F062DB3A3310E89; Path=/xyzzy; Secure This is further documented at: http://www.ietf.org/rfc/rfc2109.txt However, you can also set a second cookie, _without_ the secure option, from the SSL response. The browser will then include that cookie value in further requests to the non-secure site at the same domain. You would have to customize the non-secure site's security so that it checks for this cookie and automatically logs the user in to the non-secure site without prompting. One thing you'll have to watch out for is the timeout of the SSL session, since it might get left alone for many hours. You have two choices there: 1) either include an SSL-protected icon on every page, which will keep your SSL session from timing out. This can have some slight complications, since most browsers use some visual cue to indicated SSL traffic. 2) or just set the SSL app's session timeout to a fairly long time. -- Steven J. Owens [EMAIL PROTECTED] "I'm going to make broad, sweeping generalizations and strong, declarative statements, because otherwise I'll be here all night and this document will be four times longer and much less fun to read. Take it all with a grain of salt." - http://darksleep.com/notablog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [java] RE: http->https url rewrite bug TC 5.0.28?
Hi, Someone else already explained it well. It's not impossible, you can do it with a bit of coding. But the container can't do that bit of coding for you as it's a security risk. Yoav Shapira http://www.yoavshapira.com >-Original Message- >From: Paulo Alvim [mailto:[EMAIL PROTECTED] >Sent: Monday, November 15, 2004 3:13 PM >To: Tomcat Users List >Subject: RES: [java] RE: http->https url rewrite bug TC 5.0.28? > >Hi Yoav, > >I have a similar problem: I'd like to use https only with the login.jsp >page >and come back to http after that. Could you explain why it isn't possible? > >-Mensagem original- >De: Shapira, Yoav [mailto:[EMAIL PROTECTED] >Enviada em: segunda-feira, 15 de novembro de 2004 12:24 >Para: Tomcat Users List >Assunto: [java] RE: http->https url rewrite bug TC 5.0.28? > > > >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=9E490ADF8FB268E3F6BC 5 >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/pl a >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=9E490ADF8FB268E3F6BC5FA2FD 6 >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] >> >> >> >type="javax.sql.DataSource"/> >> >> >>[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? >>
RES: [java] RE: http->https url rewrite bug TC 5.0.28?
Hi Yoav, I have a similar problem: I'd like to use https only with the login.jsp page and come back to http after that. Could you explain why it isn't possible? -Mensagem original- De: Shapira, Yoav [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 15 de novembro de 2004 12:24 Para: Tomcat Users List Assunto: [java] RE: http->https url rewrite bug TC 5.0.28? 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] > > > type="javax.sql.DataSource"/> > > >[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=xxx" 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http->https url rewrite bug TC 5.0.28?
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:[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] [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=xxx" 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 r
RE: http->https url rewrite bug TC 5.0.28?
Yoav Either you're wrong or Tomcat 5.0.x may be broken... With cookies enabled you can transfer the session from a non-secure connection to a secure connection for the same domain/webapp. Tomcat does NOT generate a new (secure) session. The problem is that TC 5.0.28 does not exhibit the same behaviour when cookies are disabled. In this case, Tomcat does in fact generate a new (secure) session. So what we have here appears to be non-consistant behaviour from Tomcat based on client behaviour beyond the control of the web app developer... :( And all because response.encodeRedirectURL(url) did not append the jsessionid to the URL when switching protocols. If encodeRedirectURL appended the session id, then you would have consistant behaviour from Tomcat. Now it could be that using response.encodeRedirectURL(url) is not the correct way to pass the session from an http to https connection. And in fact the only way to guarantee that the non-secure session data is passed to the secure connection is using the following hack: url = url + ";jsessionid=" + session.getId() when cookies are disabled. My personal preference is to create a new static method which takes the current request and the new request URL and generates a correctly rewritten URL (based on the fact that I want the non-secure session passed to the secure pages). And to use that whereever I have been using response.encodeRedirectURL(url) and response.encodeURL(url) I still that Tomcat is broken/inconsistant on this point... Any other thoughts or solutions, anyone? John Sidney-Woollett Yoav Shapira 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: http->https url rewrite bug TC 5.0.28?
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] > > > type="javax.sql.DataSource"/> > > >[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=xxx" 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]
Re: http->https url rewrite bug TC 5.0.28?
I should have mentioned that the problem I'm seeing is causing a new session to be created after the redirect when in fact I want the original session data prior to the redirect... John Sidney-Woollett John Sidney-Woollett wrote: 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=9E490ADF8FB268E3F6BC5FA2FD61E8CF 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/plain;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=9E490ADF8FB268E3F6BC5FA2FD61E8CF 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] [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=xxx" 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]