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

Help / Discuss
#1

I can’t edit pages any more in the principal wiki (it still works in subwikis). Maybe it’s linked to the recent update - I’ve noticed a lot of changes included some social features.
I checked that page creation and deletion still work.
Many thanks in advance.

1 Like
#2

You need to check the server logs for error messages that may be logged when trying to edit a page, and you should also look at the Network tab from the browser’s developer tools to get more information on the failed lock request (check the response).

#3

Thanks @mflorea ,
I have nothing in the catalina log. The network tab gives us nothing after the 302 InplaceEditing get request - no response.
But I also noticed, on the console, an error related to load block of the mixed active content.

#4

We also noticed that it works using WYSIWYG edition.

#5

You don’t have any HTTP requests there with 4xx or 5xx status code? “failed to lock the page” suggests that the lock request has failed, and 302 (redirect) is not a failure. Are there any JavaScript errors in the Console tab?

#6

Capture du 2020-10-23 14-24-57 nothing after 302.
Capture du 2020-10-23 14-25-50 and a “TypeError : b is Null” message I had already before

#7

For some reason the request URL to lock the page uses http instead of https. Your browser is configured not to send such requests from a page with https.
This might be some problem with the configuration or the setup. Is in the Wiki descriptor for the main wiki the “Secure” flag set?

#8

Dear Clemens,
You’re right, it seems to call the http page, well spotted !
But I checked and the secure flag is set in the wiki descriptor of the main wiki.
Is there something else to check ?

#9

If there is an apache or nginx running in front of the servlet engine, doing the HTTPS encryption, then XWiki in the backend might think that the request came in via plain HTTP and thus responds via HTTP sometimes.

If the servlet container is tomcat, adding a scheme="https" to the relevant <Connector element in the server.xml often helps.

#10

Hello,
We tested your proposal @ClemensRobbenhaar , many thanks.
The problem is that doing that, the URL got back to local 8080 and xwiki is not reachable any more then.
We use nginx as a proxy as you well guessed. So there might be some interference with the server settings.

#11

I have the exact same problem. Is there a solution?

I have installed XWiki using the official docker image from GitHub - xwiki/xwiki-docker: Dockerfile to build and run XWiki on docker with docker compose and mysql.

What can I do to fix this? In the current state, xwiki is unusable.

#12

XWiki doesn’t have any known problem (that I know of) regarding HTTPS. There are plenty of instances around the world using that. So if there’s an issue , I’d say it’s with the way you’ve setup your front end to use HTTPS somehow. Could you check it?

#13

I just followed the installation guide of the docker image and chose to use docker compose. I did not change any settings there.

My server uses plesk for administration and I you can just check “Use Let’s Encrypt” for https which I did. And then I put the following proxy rule for my xwiki subdomain in plesk (see screenshot).

docker

Interestingly, everything else in xwiki works with https. It is only the “edit” button that does not work. So, maybe it’s just one setting in xwiki that I missed? Or something like this?

#14

There’s no setting for that in XWiki. Actually there’s nothing to do to support HTTPS in xwiki, see https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/#HHTTPS2FSSL

#15

What is then the reason for the “failed to lock the page” message? Is there a documentation somewhere that explains in which situations this message appears? And how to fix it?

#16

I had the same battle with Apache to Tomcat and xWiki… easy “fix”: configure Tomcat to listen to https (like 8443) and use any certificate you want (self signed or whatever). As long as you have a reverse proxy in front that does not care about the backend certificate, you are fine … HTH

#17

thanks for your answer! how do I configure tomcat in such a way? (I’m using the docker image). Can you hint me to a tutorial or something?

#18

I don’t know the version and setup of the docker image as I never used it. But this should be straight forward by generating a certificate (pkcs should do), and then enable the connector in the server.xml. Make a copy of the server.xml to have a fallback. Then re-configure the reverse proxy to point to the https port (declaring the https scheme to connect to the backend)

#19

Same problem here on both 14.4.1 and 13.10.6
Steps to reproduce:

  1. create subwiki
  2. log in to that subwiki as a read-write user which is NOT the owner
  3. create a page, save
  4. try to edit recently created page - you’ll get the ‘failed to lock page’ message

Prerequisites:

  1. The xwiki is served via https
  2. The default editor is Wysiwyg

The reason is:

  1. browser sends the lock-request GET https://domain/get/Main?action=lock...
  2. xwiki (the application itself) answers 302 location httP://domain/...

And it doesn’t matter what the SSL and Port settings of the subwiki and/or mainwiki are set to

It is a bug. Maybe thats a Wysiwys-editors bug, but THERE IS a problem

WORKAROUND
I’ve installed the Realtime WYSIWYG Editor, assigned it as a default editor and it did the trick

  • XWiki 13.10.6
  • Realtime WYSIWYG Editor 13.10.6
1 Like
#20

I faced the same problem, and it actually has to do with the configuration of Tomcat. @vmassol is right when he says there’s nothing to do to support HTTPS in XWiki. But at the same time you need to configure Tomcat and I found it hard to get the right piece of information.

Basically, the Docker container is not configured to support HTTPS by default, and the documentation on Github (https://github.com/xwiki/xwiki-docker/blob/master/README.md) does not directly contain instructions on how to make it production-ready.

You need to combine two pieces of information:

  • Concerning Docker, the information you need is here: https://github.com/xwiki/xwiki-docker#configuring-tomcat.
    The way to mount the Tomcat configuration can be found in this command: docker run --net=xwiki-nw --name xwiki -p 8080:8080 -v /tmp/xwiki:/usr/local/xwiki -v /tmp/tomcat:/usr/local/tomcat/conf -e DB_USER=xwiki -e DB_PASSWORD=xwiki -e DB_DATABASE=xwiki -e DB_HOST=mysql-xwiki xwiki:lts-mysql-tomcat.
  • To configure Tomcat you need to check the documentation on how to install XWiki within Tomcat manually. Specifically, a section contains the instructions on how to make Tomcat find the proxy headers you’re sending with NginX (x-forwarded-for and x-forwarded-proto): Tomcat Installation (XWiki.org)

Once you bind-mount the correct Tomcat configuration everything works as expected. Even with your workaround I would recommend you configure Tomcat, because the edit button is not the only broken feature: the extension interface was not loading correctly in my case.

So that’s it, everything one needs is documented, but in unexpected places :slight_smile: . I’d be interested in contributing to improve the Docker documentation. Since it’s on Github is it okay if I simply send a merge request?