XWiki Public Address not resolving properly

Raised as a consequence of this conversion in the XWiki Forum as requested by Thomas Mortagne. He suggests that this issue may be due to a tomcat configuration issue within the docker image.

Using the 12.10.7-mysql-tomcat tag from Docker Hub, when code within XWiki is using XWiki#getRequestURL (which in turn uses HttpServletRequest#getRequestURL) the URL returned is the one on which the app server received the request, not the one the client used to send the initial request.

As such, if XWiki is behind a Reverse Proxy such that the RP is serving HTTPS (and the certificate) whilst XWiki is on HTTP on an internal host/domain, the XWiki#getRequestURL will give return the URL of the internal host/domain, not the external address of the RP. Where that value is sent back to the client, for instance in a redirect, the client would be given the private/internal domain and HTTP URL rather than the public HTTPS URL.

The bug is highlighted by the following snippet:

XWiki#getRequestURL
{{velocity}}
$xwiki.getXWiki().getRequestURL($request)
{{/velocity}}


HttpServletUtils#getSourceURL
{{groovy}}
org.xwiki.container.servlet.HttpServletUtils.getSourceURL(request)
{{/groovy}}

XWiki#getRequestURL which rely on the application server return the wrong URL (proper host but wrong protocol) while HttpServletUtils#getSourceURL which is a different XWiki implementation works fine (proper host and protocol) so it suggests the proxy does send everything needed to find the source URL but for some reason the application server only partially gets it.

As per the conversation in the forum, this page demonstrates the issue as well: https://tuska.myxwiki.org/xwiki/bin/view/Test/getRequestURL/ (note the value under XWiki#getRequestURL has HTTP as the protocol, rather than HTTPS).

This was originally seen whilst using the OpenID Connect Authenticator extension and a workaround/fix as been applied there as part of OIDC-112.

I have raised this as the default Major priority out of ignorance of how important you believe this issue to be. Please re-prioritise as you see fit.

Environment Details

The environment in which this was first seen was a Kubernetes cluster in which the Ingress (ingress-nginx) is configured with a public address that serves only HTTPS and the certificate. XWiki is deployed within the cluster but is only listening on 8080/HTTP. Any HTTP requests coming into the cluster are redirected to HTTPS and the ingress is offloading so the traffic between the ingress controller and XWiki is HTTP. When the OpenID Connect Authenticator extension was deployed, after logging in (via our own auth server) the browser traffic could be seen to drop to HTTP when returning to the original page (before login). The Ingress was causing the HTTP to be upgraded to HTTPS (via redirect) but the drop to HTTP required investigation.

The ingress is configured to populate the x-forwarded-*** headers accordingly before passing the traffic on to the relevant pod.