On 01/07/2010 20:11, John-Paul Ranaudo wrote:
> 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.
Given some examples of URLs that fail, and bits of code/HTML/JSP that
are relevant would be a start.
p
> Thanks.
>=20
> On Thu, Jul 1, 2010 at 2:54 PM, Pid <pid@pidster.com
> <mailto:pid@pidster.com>> wrote:
>=20
> On 01/07/2010 19:38, John-Paul Ranaudo wrote:
> > I did more tracing and remote debugging and I was mistaken (too m=
any
> > 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 th=
e
> wrong
> > scheme. HTTP instead of HTTPS. I need a way of knowing which fram=
ework
> > 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.
>=20
> I wondering too, but mostly because you're not really giving us any=
real
> information about what's happening.
>=20
> The word 'framework' might mean something specific to you, but it
> doesn't help me understand what's happening on your server(s).
>=20
> We can't help you without accurate and detailed information.
>=20
>=20
> I /guess/ that virtual hosts won't help you.
>=20
> I /guess/ that the domain it's coming from won't matter so much as =
the
> domain requested.
>=20
>=20
> p
>=20
>=20
>=20
> > On Thu, Jul 1, 2010 at 11:31 AM, Pid <pid@pidster.com
> <mailto:pid@pidster.com>
> > <mailto:pid@pidster.com <mailto:pid@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 cur=
rent
> > > configuration. Framework A does not use SSL thus uses conne=
ctor
> > 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=3D"80" protocol=3D"HTTP/1.1"
> connectionTimeout=3D"20000" />
> > > (Used by framework A)
> > > <Connector port=3D"443" protocol=3D"HTTP/1.1"
> connectionTimeout=3D"20000"
> > > scheme=3D"https" secure=3D"true" /> (Used by framework B)
> > >
> > > Now I could change the port 80 connector to have a redirect=
Port
> > > attribute like so:
> > >
> > > /
> > > <Connector port=3D"80" protocol=3D"HTTP/1.1"
> connectionTimeout=3D"20000"
> > > redirectPort=3D"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 th=
e
> 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 error=
s.
> >
> > 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 ca=
n
> > 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 <pid@pidster.com
> <mailto:pid@pidster.com>
> > <mailto:pid@pidster.com <mailto:pid@pidster.com>>
> > > <mailto:pid@pidster.com <mailto:pid@pidster.com>
> <mailto:pid@pidster.com <mailto:pid@pidster.com>>>
> > > > <mailto:pid@pidster.com <mailto:pid@pidster.com>
> <mailto:pid@pidster.com <mailto:pid@pidster.com>>
> > <mailto:pid@pidster.com <mailto:pid@pidster.com>
> <mailto:pid@pidster.com <mailto:pid@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 matchi=
ng
> > request to
> > > HTTPS by
> > > > redirecting it to the port configured in
> 'redirectPort'
> > on the
> > > HTTP
> > > > connector.
> > > >
> > > >
> > > > p
> > > >
> > > > > On 7/1/10, Pid <pid@pidster.com
> <mailto:pid@pidster.com>
> > <mailto:pid@pidster.com <mailto:pid@pidster.com>>
> <mailto:pid@pidster.com <mailto:pid@pidster.com>
> > <mailto:pid@pidster.com <mailto:pid@pidster.com>>>
> > > <mailto:pid@pidster.com <mailto:pid@pidster.com>
> <mailto:pid@pidster.com <mailto:pid@pidster.com>>
> > <mailto:pid@pidster.com <mailto:pid@pidster.com>
> <mailto:pid@pidster.com <mailto:pid@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
a=
n
> 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=3D"80" protocol=3D"HTTP/1.1"
> > > > connectionTimeout=3D"20000" />
> > > > >>> <Connector port=3D"443" protocol=3D"HTTP/1.1"=
> > > connectionTimeout=3D"20000"
> > > > >>> scheme=3D"https" secure=3D"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 reason=
s)
> > 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
hos=
ts
> > which will
> > > then
> > > > have 2
> > > > >>> different server.xml's. If I do this I can
te=
ll
> > 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 <
> > > > >>> chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>
> > <mailto:chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>>
> > > <mailto:chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>
> > <mailto:chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>>>
> > > > <mailto:chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>
> > <mailto:chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>>
> > > <mailto:chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>
> > <mailto:chris@christopherschultz.net
> <mailto:chris@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 setu=
p 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=3D"true"?
> > > > >>>
> > > > >>> No, Pid was saying that setting one of the
tw=
o
> 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=3D"true" will make
th=
e
> > 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=3D"443" <- this is the port that
the LB=
> talks to
> > > > >>> protocol=3D"HTTP/1.1"
> > > > >>> connectionTimeout=3D"20000"
> > > > >>> scheme=3D"https" <- so request.getScheme
re=
turns
> > correct value
> > > > >>> secure=3D"true" <- so request.isSecure
retur=
ns
> > correct value
> > > > >>> />
> > > > >>>
> > > > >>> There's no need to set SSLProtocol or SSLEnab=
led
> > (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
w=
hen
> > 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 returne=
d in
> > the page.
> > > > >>>
> > > > >>> Good. How about redirects?
> > > > >>>
> > > > >>>>>> I have also tried setting the
redirect por=
t
> > thinking I can
> > > > redirect
> > > > >>> requests
> > > > >>>>>> to 443 to the port 80 internally
and schem=
e to
> > 'https'.
> > > This
> > > > actually
> > > > >>>>>> had
> > > > >>>>>> the effect of making one framework
(the on=
e
> with
> > https)
> > > work
> > > > but broke
> > > > >>> the
> > > > >>>>>> other.
> > > > >>>
> > > > >>> The redirect port is only used when the serve=
r
> 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
htt=
ps://
> > on the
> > > front
> > > > and the
> > > > >>> port added if it's not the default of 443.
> > > > >>>
> > > > >>> Now, you have to remember that the port numbe=
r
> 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=3D"8080"
> > > > >>> protocol=3D"HTTP/1.1"
> > > > >>> connectionTimeout=3D"20000"
> > > > >>> redirectPort=3D"443"
> > > > >>> />
> > > > >>>
> > > > >>> <!-- secure connector -->
> > > > >>> <Connector
> > > > >>> port=3D"8443"
> > > > >>> protocol=3D"HTTP/1.1"
> > > > >>> connectionTimeout=3D"20000"
> > > > >>> scheme=3D"https" <- so request.getScheme
re=
turns
> > correct value
> > > > >>> secure=3D"true" <- so request.isSecure
retur=
ns
> > correct value
> > > > >>> />
> > > > >>>
> > > > >>> As you see, redirectPort is set to a port
tha=
t
> isn't
> > being
> > > > handled by
> > > > >>> Tomcat. That's okay, because the load-balance=
r is
> > presumably
> > > > handling
> > > > >>> requests to myhost:443, terminating the SSL,
=
and
> > proxying the
> > > > cleartext
> > > > >>> HTTP request to the "8443" connector, which
> then reports
> > > > secure=3D"true"
> > > > >>> to anyone who asks.
> > > > >>
> > > > >> Are you using a transport-guarantee element in=
your
> > web.xml?
> > > > >>
> > > > >>
> > > > >> p
> > > > >>
> > > > >>
> > > > >>> Hope that helps,
> > > > >>> -chris
> > > > >>>>
> > > > >>
> > >
> > =20
> -------------------------------------------------------------------=
--
> > > > >> To unsubscribe, e-mail:
> > users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>
> > <mailto:users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>>
> > > <mailto:users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>
> > <mailto:users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>>>
> > > > <mailto:users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>
> > <mailto:users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>>
> > > <mailto:users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>
> > <mailto:users-unsubscribe@tomcat.apache.org
> <mailto:users-unsubscribe@tomcat.apache.org>>>>
> > > > >> For additional commands, e-mail:
> > > users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>
> > <mailto:users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>>
> > <mailto:users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>
> > <mailto:users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>>>
> > > > <mailto:users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>
> > <mailto:users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>>
> > > <mailto:users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>
> > <mailto:users-help@tomcat.apache.org
> <mailto:users-help@tomcat.apache.org>>>>
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>=20
>=20
>=20
|