So, basically, I need that one dns-alias URL to be the only valid/working URL to get into the application.
Can this be done with Tomcat configuration? I've been looking at the engine and host elements, connectors, RemoteAddressFilters, etc, but nothing does what I want it to do. Is this possible with Tomcat? Or do I need to look at another way to restrict those URLs - maybe something on the network side??
Please let me know if you have any information. Thank you!
If I'm reading between the lines correctly, you have internal URLs, primary servername URLs, and alternate (alias) servername URLs. DNS should not matter. Everything ultimately get converted to an IP address before being routed to the Tomcat server, and there are lots of ways to convert a domain servername its corresponding IP address.
So, as I'm reading that, the explicit IP address or primary servername are OK, but you want to "return a pop-up" when the same URL comes in using an alternate servername. And, by the way, URLs can work with both Fully Qualified Doman names such as www.coderanch.com, simple servernames like "www" (if you're on the same domain), and synthetic servernames - such as when the user types in "coderanch.com" and it gets converted by either the client app or a domain name resolved to its FQDN (www.coderanch.com).
Yes, Tomcat can have a Valve set up to look at the servername in a URL and do things. However, you can't return both a "pop up" and a reqular HTTP response from such a request, because the "pop up" would itself be an HTTP response and you can have only one response per URL request.
Real-world cases similar to that have different applications, though. For example, a visitor to Bob's Burgers might be allowed to use the in-house WiFi, but only after agreeing to use terms. So the system detects a foreign device (usually by its MAC address), rewrites it to go to an agreements page, then sends subsequent URL requests with a token (such as a cookie) to ensure terms are being honored. Another version of that would detect incoming requests from outside the LAN and possibly limit such URLs and this might actually be done with the assistance of the F5 itself and/or a reverse proxy server such as Apache or Nginx.
In most cases, when you have multiple hostnames, there's a reason for it. One reason might be if you're providing a service and each customer accesses via a custom URL hostname. In that case, you'd set up virtual hosts and deploy a copy of whatever app(s) each user employed. It might even be the same app, but deployed using different databases, one database per customer.
The hostname is rarely what you want to restrict access by so much as whether a given client should be granted access to a given webapp and by what means.
An IDE is no substitute for an Intelligent Developer.
posted 1 week ago
You said, "So, as I'm reading that, the explicit IP address or primary servername are OK, but you want to "return a pop-up" when the same URL comes in using an alternate servername." Maybe? The explicit IP address and primary servernames are not displaying the pop-up (which is provided by going through the F5) but I need the pop-up to display.
So, the IP-address URL and the server-host URL both point to the actual server where the application resides. Hitting that IP doesn't present a pop-up.
The dns-alias URL points to the F5 (via DNS pointing to the F5 IP) where we get the 'nice' popup and then are brought to the application login.
Is there a way to force the IP-address URL and the server-host URL to redirect to the F5 URL? Ultimately, I need the pop up that is provided by hitting the F5 IP. So, I need all the various URLs to end up hitting the F5, or I need to lock down the URLs that don't provide the pop-up.
Not sure if I can accomplish this with Tomcat configuration, or if I need to look at something else. I don't think it can be configured via the F5 because the IP url and hostname URL don't go to the F5, they hit the application server directly.
I found a 'url rewrite filter' that looks promising, but it's a separate jar file to download and use which may not go over with security. But I can investigate that if it will work.
I think this is a case of mistaking the cart for the horse.
The F5 is a proxy hardware device. It's used for load-balancing in some cases, I think, and that's a whole different can of Tomcat food, but yes, so far, so good. You want the "real" address of the Tomcat server's apps to be the IP address of the F5. Also good.
In which case, your DNS services and hostfiles should be configured so that the official host of the app is the F5's address.
To obscure general traffic from bypassing the F5 - which is what I think you're really saying - put the Tomcat server on a private LAN segment behind the F5 that isn't connected to the public Internet. Or, for that matter, if it matters, to the corporate internal network. That's it. No programming required.
You might want that private net to be a DMZ, where perhaps there are admin clients and/or other non-public servers. That should be OK. Presumably any clients inside the DMZ would be strictly administrative, in which case, I would hope that they'd have been "popped" as part of their job training and wouldn't require reminders every time. If that wasn't enough, then probably the pop-up's warning should simply be the home page of the webapp, just like the FBI warning that preceeds a DVD movie.
Lots of times DMZ machines need to talk to a secondary network. For example, to database servers. So standard server hardware often comes with 2 NICs for setups like that. My own servers do that. Since the backend LAN isn't supposed to make web requests at all, I can simply block all of Tomcat's ports for that network interface and only allow traffic from the interface attached to the F5.
An IDE is no substitute for an Intelligent Developer.
posted 6 days ago
Thanks for the response! It makes sense. Not quite as easy as I was hoping, but I feel like I'm on the right track now. Thanks!
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database