Message "failed to lock the page" when tring to edit a page

Help / Discuss
#21

That’s interesting. We have a similar settings with a reverse proxy which perform the https termination. But all I configured the xwiki.cfg with xwiki.home=https://my.domain:443/ and xwiki.url.protocol=https so that xwiki is returning the correct (external) urls. No need to configure tomcat at all. I found this common with other application as well, or is this a wrong approach in this case?

See the documentation of the properties:

#-# The domain name to use when creating URLs to the default wiki. If set, the generated URLs will point to this server
#-# instead of the requested one. It should contain schema, domain and (optional) port, and the trailing /. For example:
#-# xwiki.home=http://www.xwiki.org/
#-# xwiki.home=http://wiki.mycompany.net:8080/

#-# The default protocol to use when generating an external URL. Can be overwritten in the wiki descriptor (“secure” property).
#-# If not set, the following is used:
#-# * during client request for the current wiki: the protocol from the URL used by the client
#-# * for a different wiki or during background tasks (mails, etc.): information come from the wiki descriptor (also fallback on main wiki)
#-# For example:
#-# xwiki.url.protocol=https

#22

This is weird. Your solution is the first workaround I tried, without success. Something I didn’t mention in my first post is that I use Podman and not Docker. The main consequence of that is the network stack being different, but I don’t really see how it might change the end result.

May I ask what version you’re using? I’m using version 13.10.7.

Also please note that when using this piece of configuration that I linked in my previous post: https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationWAR/InstallationTomcat/#Hhttps28secure29 the internalProxies variable needs to be adapted to your needs. You have to change it to your NginX server IP or subnet. Or just delete it and in that case all private networks will be able to use it. See: RemoteIpValve (Apache Tomcat 8.5.81 API Documentation)

#23

The XWiki version we use is 14.6

#24

Thank you, I can confirm that your solution is working, using the Tomcat Installation (XWiki.org) info.

Configuring tomcat for https

Although allowing users to directly connect to tomcat is not recommended, for a variety of reasons it may be desirable to configure tomcat to serve pages over an https connection.If using another server as a HTTPS proxy (such as Nginx or Apache httpd), follow instruction below to avoid unexpected error (such as “failed to lock page”).

  • If using HTTPS for accessing XWiki, several modifications have to be made to ensure proper functionality. Since urls are generated from relative path (/xwiki/bin/show/Space/Page), Tomcat has to know which protocol to use, otherwise JSON requests with redirect fails (attachment uploads, extension updating, etc.)
  • Modify connector (in server.xml) to <Connector port=“8080” … secure=“true” scheme=“https” >
  • Modify host (in server.xml) and add Remote Ip Valve (only needed if using another server for HTTPS)
1 Like
XJetty documentation for https? ("failed to lock page" errors)
#25

I’m running XWiki 14.4.1 using the official docker image in a docker compose that includes an nginx container and an xwiki container.

phisad’s approach of changing xwiki.home & xwiki.url.protocol did not work for me.

I did not want to mess with Tomcat because I prefer to keep things simple.

And I did find a simple workaround. For whatever weird reasons, XWiki/Tomcat is generating HTTP URLs instead of HTTPS URLs for the edit button even when nginx sets the X-Forwarded-Proto header to https. To circumvent the weird Tomcat behavior, all I had to do was to use proxy_redirect in the nginx config to change the http URL for my xwiki site to the https version. This way, the HTTP URLs generated by XWiki/Tomcat for edit button clicks get changed to HTTPS.

I’m guessing that Tomcat requires the Valve setting here to care about X-Forwarded-Proto.