Hi Christopher, please see below:
1) The Tomcat valves operate on all webapps. We only need/require
this for one particular webapp without affecting the others.
Not true; see Konstantin's response.
Yes, I realized per-context valve configuration was possible after I
sent my original email.
2) The code has been simplified for illustration purposes. Besides
X-Forwarded-For, we detect and work around many other custom
external mobile proxies which do not use X-Forwarded-For and
require custom Geolocation code to detect the ISP and connection
type (Google Compression Proxy, Nokia OVI, Novarra, Lotus Flare,
Opera Mini, Opera Max, Samsung Max, etc.) - this kind of
customization is not possible without custom code.
Interesting. Is this something you think would be widely useful
Not sure how useful it would be to other users. We are a fairly
specialized shop running platforms for mobile carriers, so mobile
carrier detection, MSISDN header enrichment, detecting whether users are
on a real 3G/4G network or through a modem, hotspot or proxy, etc. are a
major concern for us, but I don't believe most users would care about this.
and/or would be willing to share with the community?
We'd be willing to share our code, however see my comments above.
If it's a fast-moving
target (e.g. new public proxies are popping-up all the time, or
existing proxies keep changing their configuration requirements) then
maybe it's not a great fit for a stable product like Tomcat.
Most of our proxy detection logic works by checking geolocation data
from trusted, paid sources (MaxMind and Digital Element/NetAcuity) so
even if the logic is simpe, it requires fresh, updated data from a
trusted third-party to be of any use.
On the other hand, some of the proxy detection logic instead depends on
proprietary header analysis (for instance, Opera Mini inserts many
X-OperaMini- prefixed headers).
On the other hand, if it could be configured relatively easily (like
with a "proxy definitions" file or something), then it could still be
very valuable even with a simple or default configuration which only
supports some very large proxies (e.g. Akamai, CloudFront, CloudFlare,
etc.).
This is only useful for small, well-known partner proxies that are
supposed to notify us if their IP addresses change.
But major proxies change their IP ranges all the time. So, again, this
would not really be useful without the third-party geolocation data.
This filter is not meant for detecting internal proxies within our
control (such as Apache front ends or load balancers), but rather
public proxies which are "transparently" (not really) used via
some mobile devices and services.
Does it matter whether these are "internal" versus "external" proxies?
The only real difference is the IP-range of the proxy, right?
No, that's not the only difference. Some proxies introduce non-standard
behaviour, even if they advertise themselves as "trasparent":
- Novarra proxy transcodes HTML for small screens (this proxy is
obsolete, but is a prime example of non-transparency)
- Opera Mini does all sorts of fancy things to compress responses: it
coalesces HTML, images, and JavaScript payloads to minimize the number
of streams; modifies HTML to fit devices with small screens and/or low
memory/CPU resources, etc.
- Chrome Compression Proxy (aka "Data Saver mode") is fairly
transparent, but there are many caveats. In particular, MSISDN header
enrichment breaks, which is a major issue for services we manage for
mobile carriers. See
https://developer.chrome.com/multidevice/data-compression-for-isps for
more details.
- etc.
It doesn't matter whether you control the proxy or it's an external
service: you still have to secure and validate the connection in the
same ways, and take the same action(s) on the server-end where you
trust the information being presented.
See comments above.
*Manuel Dominguez Sarmiento*
