No we are not. On 7/1/10, Pid <p...@pidster.com> wrote: > On 01/07/2010 03:42, John-Paul Ranaudo wrote: >> I have now realized the root of the problem. The cause of the problem is >> that the load balancer will sometimes proxy an HTTPS request as an HTTP >> request so when we send back a redirect we send it back with the wrong >> scheme (HTTP). So here is my current configuration: >> >> <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" /> >> <Connector port="443" protocol="HTTP/1.1" connectionTimeout="20000" >> scheme="https" secure="true" /> >> >> Port 443 is not really handling the SSL because the load balancer is. I >> set >> "secure" to true to mark the connections as secure to tomcat and not >> needing >> SSL decryption as recommended. >> >> The one framework in which uses HTTPS will send most request as HTTPS >> however the load balancer (for unknown reasons) proxies the request as >> HTTP >> (port 80). So now when we send a redirect it's to HTTP (port 80) not HTTPS >> (port 443). It should be port 443. >> >> Any idea how I can handle this in a connector configuration? >> >> My first thought is to create two virtual hosts which will then have 2 >> different server.xml's. If I do this I can tell tomcat to proxy all HTTP >> (port 80) requests to port 443 but only for that one virtual host (which >> contains the problem framework). >> >> Any thoughts? >> >> Thanks and Regards, >> >> John-Paul Ranaudo >> Application Architect >> >> On Fri, Jun 25, 2010 at 2:22 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >> John-Paul, >> >> On 6/25/2010 1:40 PM, John-Paul Ranaudo wrote: >>>>> Ok, so I am assuming I do not have to setup SSL (certificates etc) >>>>> since >> my >>>>> load balancer is decoding the connection. So even if the load balancer >>>>> is >>>>> "decoding" the connection I still have to have SSLEnabled="true"? >> >> No, Pid was saying that setting one of the two options (SSLEnabled and >> secure) to "true" makes sense... setting both to "false" is not >> particularly useful. >> >>>>> However if >>>>> I do, does this not make Tomcat try and decode the "connection"? >> >> Yes, setting SSLEnabled="true" will make the connector try to perform >> the decryption. >> >>>>> *Which is the root of my problem. How to use the HTTPS protocol without >>>>> having Tomcat decrypt the connection since the load balancer has done >> this >>>>> for me. * >> >> It sounds like you just want Tomcat to know that the connection is >> secure, but without actually doing the decryption. You should be able to >> do it like this: >> >> <Connector >> port="443" <- this is the port that the LB talks to >> protocol="HTTP/1.1" >> connectionTimeout="20000" >> scheme="https" <- so request.getScheme returns correct value >> secure="true" <- so request.isSecure returns correct value >> /> >> >> There's no need to set SSLProtocol or SSLEnabled (you're not using SSL, >> remember), they will default to "false". >> >>>>> The link to the documentation is correct. However the properties of the >>>>> connector are confusing to me. For example "SSLEnabled" if fairly >>>>> obvious >>>>> but "secure" it confusing. Not sure under what context I need to set >> this. >> >> You can set these to different values, for instance, to instruct the >> server to report connections as secure even when they aren't actually >> tunneled through SSL (as above). >> >>>>> The application always uses relative paths so whatever protocol the >>>>> framework is using will be what is returned in the page. >> >> Good. How about redirects? >> >>>>> I have also tried setting the redirect port thinking I can redirect >> requests >>>>> to 443 to the port 80 internally and scheme to 'https'. This actually >>>>> had >>>>> the effect of making one framework (the one with https) work but broke >> the >>>>> other. >> >> The redirect port is only used when the server decides that a webapp >> requires a secure connection (see <transport-guarantee> in web.xml), and >> the server issues a redirect to the client to upgrade the connection to >> HTTPS. The default is 443, so if a client arrives on port 80, they will >> be redirected to the same URL except with https:// on the front and the >> port added if it's not the default of 443. >> >> Now, you have to remember that the port number that does out attached to >> a redirect URL (say, https://myhost:443/foo/bar) is probably the port on >> the load-balancer the client will hit, not necessarily the port on the >> local machine. The following configuration is perfectly legitimate: >> >> <!-- non-secure connector --> >> <Connector >> port="8080" >> protocol="HTTP/1.1" >> connectionTimeout="20000" >> redirectPort="443" >> /> >> >> <!-- secure connector --> >> <Connector >> port="8443" >> protocol="HTTP/1.1" >> connectionTimeout="20000" >> scheme="https" <- so request.getScheme returns correct value >> secure="true" <- so request.isSecure returns correct value >> /> >> >> As you see, redirectPort is set to a port that isn't being handled by >> Tomcat. That's okay, because the load-balancer is presumably handling >> requests to myhost:443, terminating the SSL, and proxying the cleartext >> HTTP request to the "8443" connector, which then reports secure="true" >> to anyone who asks. > > Are you using a transport-guarantee element in your web.xml? > > > p > > >> Hope that helps, >> -chris >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> > > >
-- Sent from my mobile device --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
