nothing after 302.
and a “TypeError : b is Null” message I had already before
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?
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 ?
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.
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.
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.
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?
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).
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?
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
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?
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
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?
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)
Same problem here on both 14.4.1 and 13.10.6
Steps to reproduce:
- create subwiki
- log in to that subwiki as a read-write user which is NOT the owner
- create a page, save
- try to edit recently created page - you’ll get the ‘failed to lock page’ message
Prerequisites:
- The xwiki is served via https
- The default editor is Wysiwyg
The reason is:
- browser sends the lock-request
GET https://domain/get/Main?action=lock... - 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
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 
. 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?
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
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)
The XWiki version we use is 14.6
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
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.