HTTP Reverse Proxy for XWiki
Explanation
XWiki runs inside a Servlet Container that answers plain HTTP, by default on port 8080. An HTTP reverse proxy placed in front of it serves the wiki on the standard 80 and 443 ports, terminates HTTPS, and becomes the single place where access control, logging and rate limiting apply, so the container itself never has to be reachable by readers.
Two things change once XWiki stops receiving requests directly. The proxy becomes the only source of truth about the request the reader actually made: XWiki reads the Forwarded, X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-For headers itself and builds its links from them, so the proxy has to send them and, just as importantly, has to drop the ones a client sent, otherwise a visitor can make the wiki emit links for any address. Telling the Servlet Container to trust the same headers is worth doing as well, so that its own view of the request matches: the scheme returned to code that asks the container rather than XWiki, and the client address in its access log (see Configure Tomcat to Find Proxy Headers). And the xwiki.home property of the xwiki.cfg configuration file has to hold the public base address, because URLs built outside a request, in notification mails, for instance, have no forwarded headers to derive it from.
Both Apache HTTP Server and NginX are used in front of XWiki; the choice usually follows whichever of them is already installed and administered.
- Apache Server Key Configurations: the Apache directives a wiki needs, and the procedures that set them up on Linux, on Windows and for HTTPS.
- NginX Server Key Configurations: the equivalent NginX directives, and the procedures that set them up on Linux, on Windows and for HTTPS.
- Reverse Proxy and SSH Tunneling: reaching a wiki that runs on a machine with no public address, through a remote server.
More
To find more about the current topic, you can search or use the table below and filter the columns to narrow your choices.
