Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chuck,
On 1/8/15 6:21 PM, Caldarale, Charles R wrote:
From: dmccrthy [mailto:dmccr...@gmail.com] Subject: Re: Tomcat
7.0.56 - How to configure Tomcat/JRE 7u72 for client HTTPS Mutual
Authentication connections
I found the link below from 2008. It looks like a minor change to
the Catalina WebAppLoader class might solve the problem and let
me provide a custom HTTPS URL protocol handler. Have I misread
this?
http://tomcat.10.x6.nabble.com/Custom-URL-handlers-in-Tomcat-web-app-td2006418.html
This is for requests coming _into_ Tomcat, not any outbound
requests your webapp is doing - which Tomcat is not involved in (or
even aware of) at all. Again, you need some sort of proxy, if your
webapp cannot be changed to do the right thing.
No, this is for constructing URLs and using classes like URLConnection
to access them. If the underlying code (e.g. Apache httpclient) uses
URLConnection under the hood, then this technique will work.
This is actually what my initial suggestion was in my first reply to
this thread: install a stream handler for a particular protocol.
The thing is, I don't think you'd want to do this for *all* http://
URLs... only those that should be converted into secure ones. So you'd
have to be able to change the URL.
Another thought: use stunnel. It's probably the simplest possible
thing to set up. Have stunnel listen on a nearby host (perhaps
localhost) for non-secure HTTP connections, and connect the other end
to the "real" server's HTTPS port. We do this at $work to deal with a
product that doesn't support HTTPS internally, just as the OP is doing.
I think that the final answer is : "it depends".
I've done a few of these "proxy hacks" in the past, for various purposes, including a
couple of failed attempts too (but rich in lessons).
If you know exactly what kind of requests the client (the webapp in this case) is sending
to what server, and you know exactly what it gets in response, then you can usually do
something of the "man in the middle" kind of thing.
But by experience, some websites return really nightmarish stuff, full of re-directs,
javascript modules making their own connections elsewhere, cookies containing information
needed to access follow-up pages and whatnot, and that can quickly become unmanageable.
(Think Akamai, ads and analytics sites, www.bbc.com and img.bbc.com, balancing
proxies etc..)
I have a couple of questions here, for my own edification but I believe also on-topic for
the OP :
We have this webapp making a HTTP connection on the side, to some third-party
host.
It is a fair bet that the creators of that webapp did not start from scratch, and that
they used some existing library to do that (à la httpclient as Chris suggested).
First question thus : even not having the source code of the webapp, can one easily find
out what it uses in order to make that HTTP connection ?
Assuming that the answer to the previous question is yes, second question :
If a webapp "invokes" a given class to create such a connection, where does java look
first for the corresponding class ? in the webapp's own WEB-INF/classes or WEB-INF/lib ?
And if the answer to that is also yes, can one place a jar there, with classes having the
same name as the one which the webapp would normally invoke, and which would be found
first/override the usual ones it uses ?
And could such a class examine the original request URL, and if it is not one that it
should intercept and massage, just delegate the call to the similarly-named "normal" class ?
Or is there something fundamentally uncouth/illegal/fattening in such a scheme ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
