Hi,
I recently deployed XWiki Enterprise behind an Apache HTTP server acting as
a reverse proxy. This was done in order to map the XWiki web interface into
our intranet namespace and to perform SSL termination. To get this working,
I had to resort to a few hacks and workarounds due to the fact that not all
parts of XWIki Enterprise seem to be friendly towards reverse proxies. A
workable solution was eventually achieved through config file changes and
the addition of some Apache URL rewrite rules (e.g. redirect all requests
for "http://foo.com/xwiki/bar" to "https://foo.com/xwiki/bar").
Today, I had to deploy another XWiki instance behind an Apache HTTP server,
again for reasons of namespace consolidation and SSL termination. However,
this time I do not have as much freedom as I had on the previous server and
are finding myself stuck at this point. Examples of specific issues are that
URLs of skin resources are served using the HTTP (i.e. insecure) protocol
and some redirects are generated for the local address instead of the
proxied address (e.g. login page from unauthorised and default post login
redirect page).
I'm not looking for particular solutions to these issues as much as trying
to establish how likely I am to get this right and whether I'm trying to fit
a square peg into a round hole. Specific questions as follows:
1. Did anyone manage to successfully deploy XWiki behind an HTTP reverse
proxy without resorting to hacks and workarounds ? If so, please share some
information about the magic configuration. Does the problem, perhaps, lie
with Apache's reverse proxy module or its interaction with XWiki ?
2. Is my expectation to have XWiki working behind an HTTP reverse proxy
misplaced ? If not, and XWiki does intend to support this, are the issues I
describe above well known or should I report them somewhere ? Also, what can
I do to help and contribute to such an effort ?
3. Are these issues due to the platform or the layers above it (e.g. skins
and apps) ? Does the platform provide a "right way" that the layers above it
can use to generate URLs that would always work correctly through a reverse
proxy ?
BTW, thanks for a great product!
Regards,
Gerhard
--
Gerhard Esterhuizen
Director
Yila Consulting (Pty) Ltd
PO Box 50461, Waterfront 8002, South Africa
Phone: +27 82 370 9737
Fax: 086 549 5635
gerhard(a)yilaconsulting.com
align. architect. execute.