Seems just the thing I need for a particular project. By default, the postgrest server listens on port 3000
The only port on the host I've access to, which hosts Postgresql, Tomcat & postgrest, that the firewall exposes to the outside world, is (say) 2345 and connections to that port are serviced by Tomcat.
So, I was looking to see if I can somehow get Tomcat to take any http requests from the outside world for
send them on to postgrest & return the response to the outside world. I came across
Does anyone here use UrlRewriteFilter?
Is it suitable for this task?
What would urlrewrite.xml have to look like?
A ReST API via a Tomcat webapp is OK, however, as long as you secure it properly.
A URL in the form https://mydomain.com/api is actually equivalent to https://mydomain.com:443/api, since port 443 is the default port for https, just as port 80 is the default port for http. But any port numbered less than 4096 is considered "privileged". Only an app with administrator rights is allowed to open it.
If it were not for that, you wouldn't need any URL rewriting, since you could simply name your server www.mydomain.com and deploy the webapp under the context path of "/api". But running Tomcat as a privileged user is a security risk. So more commonly, people employ a reverse proxy to be the actual outside interface and have the proxy forward requests to Tomcat (usually via Tomcat port 8009).
There are many choices available for a reverse proxy. Apache Tomcat is popular because it can simultaneously host non-Java webapps. So is Nginx, which is very easy to configure and has less overhead. I'm virtually certain that there's a Tomcat reverse proxy for IIS. And those are just the most common options.
You can also employ hardware solutions. Products like F5 are essentially dedicated proxy servers that are installed between Tomcat and the rest of the world. On Linux systems, you can forward port 443 wholesale to Tomcat's port 8443 (via iptables) and set up SSL.
Tim Holloway wrote:Just to be clear - you shouldn't even think of allowing an outsider to connect directly to a database.
Yes, that's the reason I'm interested in postgrest. All the security is defined in the database, and it determines which, if any, tables, views, stored procedures & so on are available via the rest api
Tim Holloway wrote:
A URL in the form https://mydomain.com/api is actually equivalent to https://mydomain.com:443/api, since port 443 is the default port for https, just as port 80 is the default port for http. But any port numbered less than 4096 is considered "privileged".
yep, I'm ok with that. The Tomcat server I want to use already has a number of web applications running on it, accessible via https. The only port visible to the outside world is the one that Tomcat uses, say 2345. In fact, Tomcat is using https, but on 2345, not 443. I don't want to open any more ports in the firewall.
Tim Holloway wrote:
If it were not for that, you wouldn't need any URL rewriting, since you could simply name your server www.mydomain.com and deploy the webapp under the context path of "/api".
Postgrest isn't a webapp that runs inside Tomcat It's a stand alone application that responds to http requests, written afaik in Haskell, listening on port 3000.
So, what I need is an application on Tomcat, visible at say https://mydomain.com:2345/api where all requests to that application get sent on to the postgrest application running on the same host.
Rather than write any such thing myself, I thought I could make a do-nothing web app called 'api' & use UrlRewriteFilter
Hopefully, that makes more sense.
What you are actually doing is asking if Tomcat can operate as a reverse proxy server for PostgREST. And, no, I don't think that the URL rewriter would be able to do that - it rewrites URLs, it doesn't re-route them.
Port 2345 is not a good option for Tomcat to begin with. It's lower than the magic number for unprivileged servers, so Tomcat is potentially exploitable. In any event, a url in the form https://www.mydomain.com/api would NOT be sent to port 2345 regardless of whether Tomcat, PostgREST, or something entirely different was listening there. The "https" protocol is sent by your client to port 443 unless you explicitly provide an alternate port number.
What I'd actually recommend would be one of the reverse proxies I already mentioned. Apache's mod_proxy should be able to to what you want both for PostgREST and for Tomcat. So should the proxy mechanism in Nginx.
You also get additional advantages this way. First, your backend servers won't have to run as privileged users and secondly, most ISP services already have ports 80 and 443 open in their firewalls.
Seems I'm barking up the wrong tree there, I was supposing UrlRewriteFilter could do that.
At http://tuckey.org/urlrewrite/ it says that UrlRewriteFilter
Allows you to forward or redirect to other URL's based on the date/time (good for planned outages).
I'll look at some of the other technologies you suggest.
Tim Holloway wrote:
Port 2345 is not a good option for Tomcat to begin with.
ok. 2345 is not the actual port number I'm using. I'm not using mydomain.com either