Rainer Jung wrote:
On 17.12.2009 10:02, André Warnier wrote:
Martin B. Smith wrote:
On 12/16/2009 11:01 PM, Bill Barker wrote:
"André Warnier" <a...@ice-sa.com> wrote in message
news:4b294eb6.4090...@ice-sa.com...
Martin B. Smith wrote:
Howdy!
I'm trying to ensure that only specific instances of Apache are
allowed to proxy requests into my Tomcat 5.5.28 instances.
...
Yes, but if the OP wants to block all access to Tomcat, it is even
easier to just not have the worker configured on those Apaches that
shouldn't contact it.
That assumes that the OP has access to the Apache webservers he wants to
block. And it does not block an Apache webserver, controlled by someone
else, to insert the proxying statements to use the Tomcat.
That's why I was thinking of the "secret". This way, only the webservers
to which Bill gives the secret would be able to connect.
As a result, I'm guessing that the OP wants to restrict access to
certain webapps.
The good news is that with the AJP connector, request.getLocalName()
returns the name of the Apache server (as specified by the ServerName
directive), not the Tomcat server. And request.getLocalAddr() returns
the IP address of request.getLocalName() as it resolves on the Tomcat
machine. With that information it isn't hard to write a Filter that
does what you want. For the truely lazy, it would also be trivial to
copy RemoteAddrValve to LocalAddrValve and have it check localAddr
instead of remoteAddr.
Right. But this makes another couple of assumptions : 1) that the OP is
a Java programmer and 2) that he can insert a filter or a Valve into
Tomcat (as opposed to just being someone who can change some
configuration elements).
...
André, thank you for the suggestions. I had considered them, but wanted
some additional, more specific protections without going to mod_jk.
In the meantime, I checked on the Apache forum.
Unfortunately, as it stands now, some AJP parameters can be set in
Apache via the "key=value" elements of ProxyPass and ProxySet, but
unfortunately it seems that "secret" is not amongst them.
Bill, your post is a gem. Indeed, I can always use network ACLs and
iptables and mod_jk, but I was really hoping to do mod_proxy_balancer.
While there's some administrative separations between the programmers
and the system administrators that prevent me from writing servlets on
top of Tomcat, this is a nice tip.
All in all, I personally like Bill's "lazy" suggestion the best : create
another Address Valve that checks the local instead of the client
address.
It will be hard to find a workaround, that cannot be forged. If it is
more about administrative control and not so much about security, then
the getLocal* stuff might suffice, or you can add a request header via
mod_headers in Apache and check for that header in your Tomcat filter.
Using the real IP address were the connection came from of course would
make it much harder to manipulate. I don't know how to do that at the
moment.
This is an interesting discussion, which maybe also ties into the other
thread about detecting early that a client as gone away.
Just as a suggestion/question by someone who has no idea how the code is
structured : how flexible is the <Connector> with respect to the Java
Servlet Spec ? How about doing this at the Connector level ?
After all, that one should be the first in line to know
a) where this connection is coming from
b) if the connection to the client is still alive
On the face of it (to me anyway), it just looks like moving some code
from a Valve to the Connector, and maybe save the overhead of a Valve in
the process. Which Valve is Tomcat-specific anyway.
mod_proxy_ajp doesn't support the "secure" attribute, not only per
documentation, but I also checked the source code.
Nice confirmation. Thanks.
Of course "secure" is
only secure as long as you can't read the config files or sniff the
traffic. The same would be true for adding and checking a custom request
header.
Right. But I believe that in this case, we can reasonable suppose that
these Apache/Tomcat connections are over a relatively private channel,
not over the Internet. Otherwise, there is always the iptables/firewall
solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
