Carlos Villegas wrote:
If you're using apache httpd2 as your frontend main server, it's also possible
to configure it as a reverse proxy mapping a specific path in the frontend, to
reverse proxy from the xxeserver, passing websockets and all in a tunnel. That
way you don't have to expose the xxeserver port publicly, it only has to be
accessible from the apache server. The frontend server will do all the TLS/SSL.
If you map it to the same /xxe/ws default path, you don't even have to specify
a serverurl parameter in the client. I believe that's the case. You'd use the
non-ssl port in xxeserver and proxy settings as the SSL is done or can be done
entirely by the proxy, tunneling plain text to the xxeserver and keeping
everything secure.
Or you can use a dedicated reverse proxy like NGINX or haproxy, in that case
you'd proxy your main web server to the root path and /xxe/ws to the xxeserver
making sure to pass websockets. And only the proxy server needs to be
accessible publicly, usually doing all the security. I believe other web
servers like the nodejs servers have also reverse proxy capabilities that can
achieve the same thing.
In our testing set up, which is deployed in a Kubernetes cluster, we simply use
an ingress controller, which is the standard thing in Kubernetes and is often
based on a NGINX server, mapping the xxeserver to the default /xxe/ws path, the
xxeserver running in a docker container pod, and our main web app in a
different pod running its own web server. The ingress handles security and url
mappings and hides the xxeserver and main web server internally.
Hello,
Thank you very much for this very useful Apache httpd2 tip. We'll almost
certainly give it a try in the future. (We are currently about to
release XXE v11.0.)
Also thank you for sharing your experience with Kubernetes, Ingress and
Docker.
Cheers,
--
XMLmind XML Editor Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
