How Collabora Online and XWiki integration lets teams edit Office files in wiki pages
Collabora Online is the browser editor in this integration, and XWiki acts as the WOPI host through the Collabora Connector App (Pro), with both services running on infrastructure you control. For a knowledge base or intranet team, the goal is that Word, Excel and PowerPoint files attached to or stored alongside wiki pages open and get edited in the browser without sending people to a separate file store. Collabora lists xWiki among its WOPI integrations on its Collabora Online product page, which confirms the category but not the details of this connector. Before you plan the work, confirm with XWiki SAS and Collabora the connector's current name, whether it is available to you, which license tier includes it, and how it is installed. Those answers set the install path, the support route and the budget line, so get them in writing.
The wiki side of the build has decisions of its own. XWiki's rights model should decide who can open a document and who can edit it, and those rights need to be tested with real users before rollout, not assumed from the page permissions. The Collabora server must also reach XWiki, and XWiki must be able to reach the Collabora server over the URLs the browser uses. The Nextcloud administration manual recommends restricting WOPI requests to the Collabora server addresses and using the same protocol, preferably HTTPS, for both ends. The same reachability questions apply here, so ask the connector's documentation for its equivalent settings. Supported formats are listed on the product page as OpenDocument, docx, xlsx, pptx, PDF, RTF, CSV and Visio, but fidelity varies by file, so test your own templates and legacy pages.
What you need in place before the XWiki and Collabora integration starts
The XWiki and Collabora connection depends on six things being settled before any configuration begins: the XWiki line, the licensing tier, the Collabora deployment, network paths, trust certificates and an accountable owner. Working through them in this order avoids rework when the connector is installed.
Choose the XWiki line you will support
XWiki publishes a stable line, a long term support line and an intermediate LTS line. At the time of research the official Docker tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS. Pick the line your team can keep patched for the life of the integration, and confirm the connector version you need supports that exact line before you install anything.
Confirm the Collabora connector in your tier
The XWiki Pro page lists connectors for Google Apps, Office365 and OnlyOffice, but the Collabora connector is not named there. Ask XWiki SAS in writing whether the Collabora Connector App is available in the Pro tier and support plan you are buying, and whether it is included or sold separately. Do not assume it follows from the connectors you see listed.
Run a supported Collabora Online server
The XWiki side needs a Collabora Online server reachable at a public HTTPS URL that XWiki can use as its WOPI discovery endpoint. Choose a deployment method that your team will support, such as Docker, system packages or Kubernetes, and confirm the release branch you will run is still receiving security updates. Use a production subscription rather than CODE if the server will serve users in production.
Map network paths in both directions
The XWiki server must reach the Collabora discovery URL, and the Collabora server must reach the XWiki host to fetch and save documents over WOPI. Document each firewall rule, reverse proxy hop and DNS name for both directions before the first test. Missing return traffic is the most common cause of a document that opens and then fails to save.
Issue TLS certificates both sides trust
Both servers should use HTTPS with certificates issued by an authority that the other side trusts, including any internal certificate authority. Check that certificate chains are complete, that hostnames match the URLs in the configuration and that the renewal process covers both services. Expired or untrusted certificates produce errors that look like connector failures, so test the chain from each server before you configure the connector.
Name an owner for the connector
Assign one person or team to own the connector, its upgrades and its access rules, and name a backup. The connector touches the XWiki application, the Collabora server and the permission model for documents, so changes to any of them need a single accountable reviewer. Agree who approves XWiki and Collabora version changes before go-live so the two products are not upgraded in isolation.
Which XWiki edition and hosting model fit the Collabora connector
XWiki Standard is the free open source edition, so the connector question becomes one of build or sourcing. Without a Pro connector, your team or a partner must either write an extension against XWiki's extension mechanism or adopt a third-party connector and validate it. The choice changes who answers when something breaks: your own engineers and the open source community, not a vendor support desk.
- Build effort: Someone must write and maintain the WOPI client logic, including discovery, access tokens and file save handling.
- Third-party code: Any community connector needs a license review, a code review and a pinned version in your change process.
- Upgrade coupling: Moving between the stable line and an LTS line can break a custom extension, so test the connector against the target version before you upgrade.
- Support boundary: No XWiki SAS support contract covers a custom connector by default, so ask XWiki SAS what support it would offer, if any.
Confirm that the connector you plan to use is compatible with the XWiki line you run before you choose a build path.
XWiki Pro combines XWiki with business applications, connectors and XWiki SAS support. The public Pro page lists Active Directory and Azure Active Directory SSO applications, File Manager, Forum, Polls, Calendar, Ideas, Meeting, Diagram, Pro Macros, and Google Apps, Office365 and OnlyOffice connectors. That list does not name a Collabora connector, so the Collabora Connector App's availability in the Pro catalog must be confirmed before you plan around it.
- Connector availability: Ask XWiki SAS whether the Collabora Connector App is included in Pro for your target version or sold separately.
- Support scope: A Pro subscription brings vendor support for bundled applications, which determines who investigates a WOPI failure inside XWiki.
- Tier fit: Starter covers up to 25 users and is available on XWiki Cloud only, Basic covers up to 1,000 users, Business up to 10,000 and Enterprise is unlimited, so your user count sets the minimum tier.
- Identity interaction: Confirm how the bundled Active Directory or Azure AD SSO applications interact with the connector's user and permission model before you test them together.
Get the tier, the connector's inclusion and the supported version written into the quote before you commit to the design.
XWiki Cloud is hosted by XWiki SAS, which states that its cloud infrastructure is ISO 27001 certified. Starter is limited to cloud hosting, so a team that expects to exceed 25 users or needs its own network placement should plan for on-premises hosting from the start. XWiki SAS states that cloud and on-premises pricing is the same, so the hosting decision turns mainly on control, data location and network reach.
- Collabora reachability: The hosted XWiki must reach your Collabora server over HTTPS, so confirm the public endpoint, DNS and firewall path before design sign-off.
- Data location: Document content and backups sit in the vendor's hosting, so confirm regions, backup retention and deletion terms in the contract.
- Certification scope: Ask XWiki SAS for the certificate scope and the services it covers, because it does not automatically cover your own Collabora server.
- Extension policy: Confirm whether the cloud plan lets you install the connector extension you need and who approves installs.
Get the hosting location, the Collabora endpoint path and the extension policy confirmed in writing before the architecture is fixed.
On-premises hosting places XWiki and the Collabora server in infrastructure you control, so you set the WOPI network path, TLS configuration and upgrade timing. The official XWiki Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. The stable, LTS and intermediate LTS lines are tagged separately, so choose the line first and then the database variant.
- Line selection: At research time the tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS, so confirm current tags before you pin a version.
- Database variant: Pick the image variant that matches the database your team already operates, backs up and restores.
- Support purchase: XWiki SAS sells on-premises professional support, installation help and training, and consulting requires a Business or Enterprise plan at 1200 EUR per day according to XWiki SAS pricing.
- Connector delivery: The connector must be built into your image or installed into each instance, and it must be upgraded alongside XWiki.
Confirm the image variant, the XWiki line and the support tier together, because each choice affects the other two.
Why the WOPI handshake decides most of the design
The integration works only if three things agree: XWiki exposes file access to Collabora, Collabora can call back into XWiki, and both sides use the same public address for each other. WOPI is the protocol that carries this exchange. When a user opens an Office file in an XWiki page, the XWiki side acts as the WOPI host, handing the editor a URL that identifies the file and an access token, and the Collabora server then requests the file and saves changes back through the same host. Each of those requests is a network path that has to be planned, not assumed. If the editor cannot reach the host's WOPI endpoint, or the host cannot reach the editor's discovery URL, the document will not open, and the error often looks like a browser problem rather than a routing one.
The Nextcloud administration manual gives a pattern that applies well beyond Nextcloud: restrict WOPI requests to the IP addresses of the Collabora servers, and use the same protocol for the Collabora server URL as for the host, preferably HTTPS. For XWiki, the first task is to confirm whether the Collabora Connector App (Pro) and the XWiki version you run support an equivalent allow list, which addresses the host accepts WOPI traffic from, and where that setting lives. Do not promise an IP restriction to a security team until that is verified in a test environment. If the connector cannot restrict by address, plan compensating controls at the network or reverse proxy layer and record that as a residual risk.
Decide the public hostnames and TLS endpoints before installing anything. Whatever XWiki and Collabora advertise must match what the browser and the other server can resolve, including any reverse proxy, load balancer or NAT in between. Mixed schemes, such as an HTTP Collabora URL behind an HTTPS wiki, are a common cause of blocked mixed content and failed saves. Ask your XWiki and Collabora contacts to confirm in writing which URLs the connector expects, which certificates it trusts for back-channel calls, and how it behaves when a host name changes after go-live, because that choice is far harder to change once users have documents open.
How to configure XWiki and Collabora Online step by step
This sequence takes you from a running Collabora Online server to XWiki pages where office documents open, edit and save back, with a check that closes each stage. Work through it in a test environment first, then repeat it against your production hosts once every check passes.
Deploy the Collabora Online server
Your infrastructure or platform team deploys Collabora Online from a supported package or from Docker. The free CODE image, collabora/code, is suitable for testing only, because Collabora describes CODE as not recommended for production. For a production server, use a supported edition and confirm its terms on the Collabora Online pricing page. Done means the server process starts, its logs show no startup errors, and the server responds on its local port.
Set and verify the public HTTPS URL
Publish the Collabora server behind a reverse proxy with a TLS certificate that XWiki's server can trust. Then request the WOPI discovery endpoint over HTTPS from a machine on the XWiki network and confirm it returns the XML discovery document. Record the exact base URL, because the connector needs it in the next steps. Done means the discovery request succeeds with a valid certificate and no redirect to plain HTTP.
Deploy XWiki with its database
Deploy the official XWiki Docker image variant that matches your database standard, MySQL, PostgreSQL or MariaDB, each running on Tomcat. Confirm the image tag against the XWiki release line you intend to run, whether stable, the intermediate LTS or LTS, and check the official image documentation for the exact environment variables. Done means the XWiki home page loads over HTTPS, the administrator can sign in, and the database shows the XWiki schema.
Install and confirm the Collabora Connector App
Using the XWiki administration area, install the Collabora Connector App (Pro) from the extension repository. Confirm the exact menu names with the connector's own documentation, as they can change between versions. Done means the extension appears in the installed extension list with its version and status shown as installed, and no error appears in the XWiki logs after a restart.
Point the connector at the Collabora URL
In the connector settings, enter the Collabora server base URL recorded in the earlier step. Keep the protocol identical to the XWiki URL, preferably HTTPS. Then set WOPI allow rules so that only XWiki's outbound addresses can send WOPI requests to Collabora, following the same restriction the Nextcloud administration manual recommends for its own WOPI setup. Done means the connector reports the editor as reachable and the Collabora logs show the XWiki host as the WOPI caller.
Create a test space and test user
Create a test space in XWiki and grant rights to one non-administrator test user, with view and edit permissions on that space only. Confirm that a second user without those rights cannot open documents in the space. Done means the test user can see the space and the restricted user receives a denial, which proves the XWiki permission model reaches the editor.
Open and save Office files
As the test user, upload one .docx, one .xlsx and one .pptx file to the test space. Open each file in the browser editor, make a visible change, save, and reload the page. Then download the stored file and confirm the change is present and the formatting is intact. Done means all three files open, edit and save back to XWiki with the changes intact, and any fidelity differences are recorded for review before rollout.
How XWiki rights map to Collabora edit and view permissions
This table compares each XWiki permission concept with what the Collabora session receives through WOPI and what the connector documents. Read the middle column as the intended exchange and the right column as your test list. The main takeaway is that the connector's exact permission and save behavior should be confirmed in a test wiki before you grant edit rights to users.
| Concept | What Collabora receives or depends on | What to verify in your environment |
|---|---|---|
| User identity | The XWiki host sends the user identity in WOPI file information, which Collabora uses for the session and editing attribution. | Confirm which user fields the connector sends and how display names appear to co-editors. |
| View right on the page | A user who can view the page holding the attachment should be able to open the document in read mode. | Test a user with view-only rights and confirm the document opens read-only, not editable. |
| Edit right on the page | Edit access should exist only where the XWiki edit right is granted, so the host signals write permission. | Confirm an edit right on the page, not only on the attachment, is what enables editing. |
| Group-based limits | Nextcloud lets administrators limit which groups may use or edit. The connector's group controls are not documented in the sources reviewed here. | Ask the connector maintainer whether it can restrict by XWiki group, or plan to control access with page rights only. |
| Space and page inheritance | Attachments usually follow the rights of the page or space that holds them, so moved or copied pages can change access. | Move and copy a test page, then recheck view and edit results for each test user. |
| Supported document formats | The Collabora product page lists OpenDocument, docx, xlsx, pptx, PDF, RTF, CSV and Visio files. | Confirm which extensions the connector sends to the editor and which remain download-only. |
| Save behavior | Each save returns the edited file to the XWiki host. Whether it creates a new attachment version is not documented here. | Edit and save a test file, then count attachment versions and check the history entry and author. |
| Concurrent editing | Co-authoring depends on the sessions reaching the same Collabora server and on the host's lock handling. | Open the same file from two accounts and confirm both sessions see changes and the save conflict behavior. |
Security controls to set before users edit documents in wiki pages
Office editing in XWiki adds a second service that holds user documents and talks to the wiki over WOPI. The cards below are checks the team runs before users open their first document, and several depend on what the connector exposes, so confirm each one against the version you deploy.
Restrict WOPI traffic to known servers
Confirm that only your Collabora Online servers can send WOPI requests to XWiki, and that the Collabora server accepts requests only from the XWiki hosts it serves. Ask the connector maintainers whether it offers an allow list setting or whether this must be enforced at the firewall or reverse proxy. Test by sending a WOPI request from an address outside the approved list and confirming it is refused. Record the list and review it when servers change.
Use HTTPS on both sides
Serve XWiki and the Collabora Online server over HTTPS with certificates that clients trust, and make sure the URL XWiki stores for the Collabora server uses the same protocol as the wiki. Check that the certificate chain is complete on the Collabora side, because a missing intermediate certificate often breaks editing only in some browsers. Confirm that document content is not sent over plain HTTP at any hop, including internal load balancers.
Keep XWiki and the connector supported
Choose a XWiki line that still receives security fixes, and pin the connector to a version built for that line. At the time of research the official Docker tags were 18.8.0 for stable, 17.10.14 for LTS and 18.4.7 for the intermediate LTS, so confirm which line your organization has committed to. Ask the XWiki team which connector release supports your XWiki version, and plan upgrades for both together.
Separate edit rights from view rights
Check that a user who can view a wiki page is not automatically able to open the office editor or save changes. Map XWiki groups to two roles, one for viewing and one for editing, and test both with a standard user account and a guest account. Confirm whether the connector applies XWiki page rights to the document, or whether Collabora grants access on its own. Document the result, because the answer determines where access reviews must happen.
Track Collabora security advisories
Subscribe to Collabora's release notes and security advisories and assign an owner to read them. The 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and updated package signing keys for RPM and DEB users, which is a reason to check signing keys and patch levels on a fixed schedule. Confirm which branch you run, how quickly you can apply point releases, and how you will test a patch against your document formats.
Review logs and access to the server
Decide what the Collabora server logs, where those logs go, and who can read them. Check that WOPI requests from XWiki appear in your central log store, that failed access attempts are visible, and that administrator access to the Collabora host is limited and recorded. Confirm which fields the connector passes in each request so your alerts can match document, user and page identifiers. Review the logs on a set schedule and after every upgrade.
Where the XWiki and Collabora integration fails most often
This table lists the failures teams hit most often when connecting XWiki to Collabora Online, with the likely cause and a general fix for each. Start with the connector and Collabora logs, since they show the exact message that points to the failing layer. Most problems trace back to URLs, certificates, rights or allow lists rather than the document itself.
| Symptom | Likely cause | Fix |
|---|---|---|
| Editor does not load | The Collabora URL in the connector is wrong, or the certificate is not trusted by the XWiki server | Confirm the URL and port from the XWiki server itself, then check that the certificate chain is trusted there. Compare the connector log entry with the Collabora log. |
| Document opens read-only | The user or group has view rights only, or the editing permission was not granted on the page or attachment | Review the rights on the page and attachment for that user and group. Test with an account that has edit rights to separate permissions from integration faults. |
| Editing works but changes do not save | Callback from Collabora back to XWiki is blocked by a firewall, proxy or WOPI allow list | Allow traffic from the Collabora server to the XWiki address and port. Confirm the allow list on both sides includes the Collabora server address. |
| Mixed HTTP and HTTPS errors | One of the URLs (XWiki base address, connector setting or Collabora address) uses HTTP while another uses HTTPS | Set every URL to the same scheme, preferably HTTPS. Check reverse proxy headers so XWiki generates HTTPS links. |
| Office files open with wrong layout or missing fonts | Font packages are missing on the Collabora host, or the file uses formats or features the editor handles differently | Install the fonts used in your documents on the Collabora host. Test representative .docx, .xlsx and .pptx files before rollout. |
| Connector stops working after an upgrade | XWiki, the connector and Collabora Online were upgraded on different schedules, so versions no longer match | Check the connector's compatibility with your XWiki version and the Collabora release. Upgrade in a planned order and test in a staging instance first. |
What buyers ask before they hire help for the XWiki and Collabora integration
What drives the cost of an XWiki and Collabora integration project?
The cost follows the scope agreed in writing, and the main drivers are the number of users and the Collabora subscription tier, the network and certificate work between XWiki and the Collabora server, the number of XWiki spaces and documents that must be checked, and the volume of testing. Connector licensing is a separate line: the Collabora Connector App sits in XWiki Pro, and the Pro tiers are priced by user count. Ask for the quote to list each component separately, including which items are one-time (installation, configuration, testing) and which recur (subscriptions, support, upgrades). Each extra space with legacy or unusual office files adds test effort, so ask how the scope counts them.
Can our own team build the XWiki and Collabora integration without a partner?
Yes, if your team already has operators who know XWiki and operators who know Collabora Online, and if you have a written test plan. The hard parts are rarely the configuration screens. They are the WOPI addressing between XWiki and the Collabora server, TLS trust, reverse proxy behavior, and checking that office files open, save and co-edit correctly. Confirm that the people who will own the system after go-live have actually performed these steps on a test instance. A partner is most useful when those skills or the test capacity are missing.
How long does an XWiki and Collabora integration take to deliver?
The duration depends on the scope agreed in writing, so no fixed timeline applies to every project. The main variables are the number of environments (test and production), the network and certificate work needed to reach the Collabora server, the number of spaces and document types to validate, and how quickly your reviewers can sign off test results. Ask for a plan that breaks the work into phases with a named exit criterion for each, and ask what would move the dates if a dependency, such as a firewall change, takes longer than expected.
What does our organization need to provide for the integration?
The work needs named owners on your side, usually one for XWiki, one for the Collabora server and network, and one for security or compliance sign-off. It also needs network access between XWiki, the Collabora server and the users' browsers, including the ports and DNS names the design requires. Provide test users with the roles you actually use, and sample documents covering the formats your staff work with, including legacy Microsoft files and documents with macros or embedded objects. Without these inputs, testing tends to cover only the easy cases.
Do we need XWiki SAS support to run the integration?
Not necessarily. XWiki is open source under the LGPL 2.1, and the official Docker images are maintained by the XWiki Core Dev Team, so a team with the right skills can install and run it without a vendor contract. XWiki SAS offers on-premises professional support, installation and configuration help, and training. According to the XWiki pricing page, consulting costs 1200 EUR per day and requires a Business or Enterprise support plan, while training costs 1500 EUR per day. Decide which of these your team needs for the first go-live and which can wait until you see how the system performs in production.
How do Collabora subscription tiers affect support for the editor?
Collabora Online's free CODE edition is a rolling release that Collabora does not recommend for production, so a production integration should be planned on a supported subscription. According to the Collabora Online pricing page, the Business plan costs 3 euros per user per month for up to 99 users and includes long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan for 100 or more users is quoted with volume discounts and adds integration support, customization services and roadmap input. Confirm with Collabora which tier matches your user count, and check that the support terms cover the XWiki connector path you plan to use.
Which parts of the integration carry the most security and compliance risk?
The main risks sit at the boundary between XWiki and the Collabora server. The WOPI requests should be limited to known Collabora server addresses, and the Collabora server URL should use the same protocol and preferably HTTPS. Access should be controlled in XWiki itself, so you decide which users can open documents and which can edit them. Patching matters too: Collabora publishes security advisories, so the update process and the people who receive those notices should be defined before go-live. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
Who is responsible for upgrades after the integration goes live?
Responsibility is set in the written scope and the support agreement, so confirm it before you sign. Your team usually keeps responsibility for the XWiki version, the Collabora server version and the connector, and must re-test office editing after each change to either side. Ask whether the engagement includes a retest after upgrades, how release notes are reviewed, and who applies security fixes. Ongoing support, upgrades and continuous testing can be arranged as a retainer, which turns these checks into a recurring service rather than a one-off task.
How DeployOpen scopes, builds and supports this integration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Collabora Online and XWiki integration, we start from a written scope that covers the XWiki and Collabora servers, the connector and the access model, then build and test it in your environment before handover.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the XWiki version, database variant and Collabora deployment method that the integration will use.
- We confirm which XWiki Pro connectors and Collabora Connector App features are in scope, and which are excluded.
How we build
- We install the Collabora Connector App on a test XWiki instance and confirm WOPI discovery reaches your Collabora server.
- We configure WOPI allow lists, HTTPS endpoints and the groups allowed to view or edit office documents in XWiki.
- We test document creation, editing and saving across the office formats you need, with sample documents from your own spaces.
How we hand over
- You receive written configuration records, network and TLS settings, and the access model mapped to XWiki groups and rights.
- We document the test cases, results and known limitations, so your team can repeat the checks after each upgrade.
- Knowledge transfer sessions cover day-to-day administration, troubleshooting and what to recheck when either product is updated.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- A retainer can cover reviewing XWiki and Collabora release notes and security advisories before you apply updates.
- Support can include re-running the document fidelity and access tests after XWiki, Collabora or connector changes.
