On 01/07/2010 19:38, John-Paul Ranaudo wrote: > I did more tracing and remote debugging and I was mistaken (too many > late nights). Each framework is sending us the request via port 80. The > problem comes from the fact the one of the frameworks uses HTTPS before > the load balancers so when we send back a redirect it is using the wrong > scheme. HTTP instead of HTTPS. I need a way of knowing which framework > made the request so I can alter the scheme on redirect for just the one > framework. > > btw, the frameworks are proprietary and much like existing portal > frameworks. > > So I am wondering if I can do this with virtual hosts or somehow detect > the incoming URL to tell which domain its coming from and handle > appropriately.
I wondering too, but mostly because you're not really giving us any real information about what's happening. The word 'framework' might mean something specific to you, but it doesn't help me understand what's happening on your server(s). We can't help you without accurate and detailed information. I /guess/ that virtual hosts won't help you. I /guess/ that the domain it's coming from won't matter so much as the domain requested. p > On Thu, Jul 1, 2010 at 11:31 AM, Pid <p...@pidster.com > <mailto:p...@pidster.com>> wrote: > > On 01/07/2010 16:01, John-Paul Ranaudo wrote: > > I am confused no doubt. What you say here is correct: > > > > /"In your description of the issue so far, you've said that the > > application *is* using SSL. The load-balancers might be > terminating it > > & forwarding unencrypted connections"/ > > / > > / > > /I think I understand what you mean by redirecting. Our current > > configuration. Framework A does not use SSL thus uses connector > port 80. > > Framework B, the problem, uses SSL/port 443. / > > It might help illuminate matters if you explain exactly what Frameworks > A & B actually are. Are they separate web applications? How do they > relate to each other, are they on separate URLs? > > > <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" /> > > (Used by framework A) > > <Connector port="443" protocol="HTTP/1.1" connectionTimeout="20000" > > scheme="https" secure="true" /> (Used by framework B) > > > > Now I could change the port 80 connector to have a redirectPort > > attribute like so: > > > > / > > <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" > > redirectPort="443"/> > > > > The problem with this approach is that framework A which does not use > > SSL now will use it via he redirect port. We'll then get the same > mixed > > content warnings in the browser. > > It won't use it unless it's told to. So what's telling it to? > > As far as I can see, there's nothing stopping the whole site running > under 443, which would prevent you seeing mixed content errors. > > Have you identified exactly which resources are being served via HTTP > within an HTTPS page? What are they? > > > p > > > I hope this explains the problem more clearly. > > / > > / > > > > > > Redirecting as I explained below just means that you can > upgrade to > > HTTPS for specific paths. The load-balancer still handles it. > > > > > > > If we use anything that forces SSL it will fail for the other > > framework which does > > > not use SSL. > > > > Why? > > > > How are you switching back to HTTP for 'the other framework', > once the > > user has been on a page served under HTTPS? > > > > > > p > > > > > > > On Thu, Jul 1, 2010 at 3:59 AM, Pid <p...@pidster.com > <mailto:p...@pidster.com> > > <mailto:p...@pidster.com <mailto:p...@pidster.com>> > > > <mailto:p...@pidster.com <mailto:p...@pidster.com> > <mailto:p...@pidster.com <mailto:p...@pidster.com>>>> wrote: > > > > > > On 01/07/2010 08:49, John-Paul Ranaudo wrote: > > > > No we are not. > > > > > > If the SSL-only resources match a specific path, you can > add a > > > security-constraint which doesn't have user roles, but > does have a > > > transport-guarantee set to 'CONFIDENTIAL'. > > > > > > The container will automatically upgrade a matching > request to > > HTTPS by > > > redirecting it to the port configured in 'redirectPort' > on the > > HTTP > > > connector. > > > > > > > > > p > > > > > > > On 7/1/10, Pid <p...@pidster.com > <mailto:p...@pidster.com> <mailto:p...@pidster.com > <mailto:p...@pidster.com>> > > <mailto:p...@pidster.com <mailto:p...@pidster.com> > <mailto:p...@pidster.com <mailto: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 > <mailto:ch...@christopherschultz.net> > > <mailto:ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>> > > > <mailto:ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net> > > <mailto:ch...@christopherschultz.net > <mailto: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 > <mailto:users-unsubscr...@tomcat.apache.org> > > <mailto:users-unsubscr...@tomcat.apache.org > <mailto:users-unsubscr...@tomcat.apache.org>> > > > <mailto:users-unsubscr...@tomcat.apache.org > <mailto:users-unsubscr...@tomcat.apache.org> > > <mailto:users-unsubscr...@tomcat.apache.org > <mailto:users-unsubscr...@tomcat.apache.org>>> > > > >> For additional commands, e-mail: > > users-h...@tomcat.apache.org > <mailto:users-h...@tomcat.apache.org> > <mailto:users-h...@tomcat.apache.org > <mailto:users-h...@tomcat.apache.org>> > > > <mailto:users-h...@tomcat.apache.org > <mailto:users-h...@tomcat.apache.org> > > <mailto:users-h...@tomcat.apache.org > <mailto:users-h...@tomcat.apache.org>>> > > > >>>> > > > >>>> > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > >
signature.asc
Description: OpenPGP digital signature
