I wish I could provide more information. At least I have narrowed down the problem. I am having a meeting with the architects of both frameworks today so perhaps I'll get some details.
Thanks. On Thu, Jul 1, 2010 at 2:54 PM, Pid <p...@pidster.com> wrote: > 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>>> > > > > >>>> > > > > >>>> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
