Collaborative session never connects?

I set up an xwiki instance on my internal dev server to build a new documentation site for our company. Everything went great and after everything was signed off on, we moved the site to a LiquidWeb server instance.
I set up a new xwiki server and imported the content from the dev server.

Now, every time I create a new page, or edit and existing page, I get this at the bottom, and it never goes away, unless I click on it.
Screenshot 2025-06-23 at 10.50.22 AM

Any ideas for fixing this?

Something that your developer console says? You can open it in chromium browsers with F12.

Yes, looks like there’s a ton of http to https errors:

[Error] Cannot load http://help.checkinpos.com/wiki/internaldocs/jsx/CKEditor/EditSheet?sourceMap=true&minify=false&v=17.1.0&xwiki-version=17.1.0&fast-diff-version=&bs3typeahead-version=4.0.2 due to access control checks.
[Warning] [blocked] The page at https://help.checkinpos.com/wiki/internaldocs/view/Online%20info%20for%20Checkin/ requested insecure content from http://help.checkinpos.com/wiki/internaldocs/jsx/CKEditor/Translations?sourceMap=true&minify=false&language=en. This content was blocked and must be served over HTTPS.

I’ve been searching for ways to fix the errors, but none of the remedies, such as:

I can’t find the xwiki config file, and the Tomcat config file doesn’t have the section shown in this topic.

Could definitely use some help.

I found the xwiki.cfg file @ /usr/local/tomcat/webapps/ROOT/WEB-INF, and added the option to force https there, no change.

I am running the site behind NPM and using it’s built in ability to request and serve SSL certs, so I guess the problem lies there somewhere?

I just don’t know how to fix it.

Finally deciphered what I think I’m supposed to add. In tomcat’s server.xml file I updated the mentioned sections to look like so:

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
               maxParameterCount="1000"
               secure="true"
               scheme="https"
               />
        <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b"
               remoteIpHeader="x-forwarded-for"
               protocolHeader="x-forwarded-proto" />

Then I added these lines to NPM’s Advanced settings:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

But I still get:
Screenshot 2025-06-24 at 4.44.17 PM
After restarting the container.
This is driving me crazy.

None of the topics here have a clear and concise answer.

I’m still struggling with this.
Does anyone have a good set of steps that will stop the mixed content errors?

Here’s as much info as I can give. I could really use some help getting this issue resolved.

Using Docker containers to deploy xwiki and mysql with these commands:

docker run --net=xwiki-nw --name mysql-xwiki -v /opt/xwiki/mysql:/var/lib/mysql -v /opt/xwiki/mysql-init:/docker-entrypoint-initdb.d -e MYSQL_ROOT_PASSWORD=password -e MYSQL_USER=xwiki -e MYSQL_PASSWORD=password -e MYSQL_DATABASE=xwiki -d mysql:9.1 --character-set-server=utf8mb4 --collation-server=utf8mb4_bin --explicit-defaults-for-timestamp=1

docker run --net=xwiki-nw --name xwiki -p 8080:8080 -v /opt/xwiki/:/usr/local/xwiki -e DB_USER=xwiki -e DB_PASSWORD=password -e DB_DATABASE=xwiki -e DB_HOST=mysql-xwiki -d xwiki:17.1.0-mysql-tomcat

Using an external docker network to connect them.

I’m using NPM in another container to normalize the port and put an SSL certificate in play.

DNS is provided by Cloudflare

<Leia>Help me Obi Wan... you're my only hope</Leia>

This is shown by the realtime editing feature when trying to connect to the WebSocket end-point used to perform the synchronization. Since you mentioned you have a proxy in front of XWiki, you need to make sure WebSocket requests (/xwiki/websocket/*) are properly forwarded by the proxy to XWiki. I have no experience with NPM proxy, so I can’t help you with that, but I expect you should be able to find some answers by looking for “how to properly forward WebSocket requests in NPM proxy“ (which is not specific to XWiki).

@mflorea Could we have a doc page that is easily found and document all the setups we can find (we could ask the user for the config) and provide as much info as possible on xwiki.org. Then 1) we can answer these questions on the forum with a link and 2) users may be able to find them by searching on google and co. It seems it’s a common question these days. Thx!

Another idea would be to display some information messages when “connecting to the collaborative session” takes a few seconds. WDYT @mflorea?

That page is https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/#HHTTPProxy . We currently provide sample configuration only for Apache HTTPD and NginX, but both are not up-to-date in terms of WebSocket request forwarding. Any XWiki extension that uses WebSockets needs the proxy to be properly configured. This is not limited / specific to realtime editing. Unfortunately I don’t have enough experience with Apache HTTPD and NginX to suggest the proper configuration, so I welcome users that have made it work to update the documentation.

On the realtime editing documentation I added a Troubleshooting section https://extensions.xwiki.org/xwiki/bin/view/Extension/Realtime%20WYSIWYG%20Editor/#HTroubleshooting that links to the Admin Guide. But this isn’t going to be helpful as long as the Admin Guide is not up-to-date.

This notification is not displayed anymore since we introduced the new realtime editing toolbar. With the latest XWiki version you actually get Loading... . But in any case, I’m not convinced that a few seconds to connect is a good indicator that there’s a problem with the HTTP proxy configuration.

AFAIK, the Apache HTTPD configuration is up to date (all it takes is `upgrade=websocket`). Realtime editing is working fine at least.

Dear lord, I can’t believe it was that simple…

This was turned off.

1 Like

@mflorea We really have a problem because:

  1. RT editing is now the standard in XS
  2. Websocket support seems to not be setup by default (ie you need to configure something specially in your config)

This makes configuring XWiki difficult and not OOB.

What could we do (apart from providing a very good documentation - IMO that’s not the best option as ideally it should work OOB somehow)?

Thx

To qualify, this is for proxies in front of XWiki. AFAIK it’s set up by default in standard Servlet container setups (Tomcat, Jetty), right?

So to reply to my questions:

  • The servelt containers have websockets configured by default
  • The proxies don’t have websockets on by default (in general)
  • We have Loading... to fix the setup issue, to fallback to non-RT editing when the connexion doesn’t work. Only issue is waiting for the timeout…

Some further ideas:

  • Have a DW step to verify that websockets is properly configured.

What might help is when the websocket times out maybe throw up a message that says, “Realtime editing connection could not connect, make sure your web server and / or proxy is configured to allow WebSockets.”

That would have allowed me to track down the issue in 5 minutes.

1 Like