WOPI - Versionsgeschichte

Admin am 25. April 2026 um 12:57 Uhr

2026-04-25T12:57:04Z

← Nächstältere Version		Version vom 25. April 2026, 12:57 Uhr
Zeile 87:		Zeile 87:
	Ein einfacher Aufruf von außen liefert jedoch eine ausführliche Antwort:		Ein einfacher Aufruf von außen liefert jedoch eine ausführliche Antwort:

	<~~syntaxhighlight lang="bash"~~>		<pre>
	curl https://collabora.beispiel.de/hosting/discovery		curl https://collabora.beispiel.de/hosting/discovery
	</~~syntaxhighlight~~>		</pre>

	Die Antwort enthält:		Die Antwort enthält:
Zeile 119:		Zeile 119:
	alles andere mit <code>403</code> ablehnen:		alles andere mit <code>403</code> ablehnen:

	<~~syntaxhighlight lang="caddy"~~>		<pre>
	collabora.beispiel.de {		collabora.beispiel.de {
	@allowed path /browser/* /hosting/capabilities /hosting/discovery /cool/* /lool/*		@allowed path /browser/* /hosting/capabilities /hosting/discovery /cool/* /lool/*
Zeile 129:		Zeile 129:
	}		}
	}		}
	</~~syntaxhighlight~~>		</pre>

	Damit ist die Angriffsfläche auf das funktional notwendige Minimum reduziert —		Damit ist die Angriffsfläche auf das funktional notwendige Minimum reduziert —
Zeile 158:		Zeile 158:
	per Kommandozeile:		per Kommandozeile:

	<~~syntaxhighlight lang="bash"~~>		<pre>
	# Aktuellen Wert prüfen		# Aktuellen Wert prüfen
	docker exec nextcloud occ config:app:get richdocuments wopi_allowlist		docker exec nextcloud occ config:app:get richdocuments wopi_allowlist
Zeile 165:		Zeile 165:
	docker exec nextcloud occ config:app:set richdocuments wopi_allowlist \		docker exec nextcloud occ config:app:set richdocuments wopi_allowlist \
	--value="172.18.0.0/16"		--value="172.18.0.0/16"
	</~~syntaxhighlight~~>		</pre>

	=== Was eingetragen werden muss ===		=== Was eingetragen werden muss ===
Zeile 232:		Zeile 232:
	'''Der verlässliche Test:'''		'''Der verlässliche Test:'''

	<~~syntaxhighlight lang="bash"~~>		<pre>
	docker exec nextcloud curl -sk -o /dev/null -w "%{http_code}" \		docker exec nextcloud curl -sk -o /dev/null -w "%{http_code}" \
	https://collabora.beispiel.de/hosting/discovery		https://collabora.beispiel.de/hosting/discovery
	</~~syntaxhighlight~~>		</pre>

	Und direkt ein <code>.docx</code> in Nextcloud öffnen.		Und direkt ein <code>.docx</code> in Nextcloud öffnen.

Admin am 24. April 2026 um 10:59 Uhr

2026-04-24T10:59:08Z

← Nächstältere Version		Version vom 24. April 2026, 10:59 Uhr
Zeile 11:		Zeile 11:
	hinter Reverse Proxies konzipiert — was die Konfiguration entsprechend fragil macht.		hinter Reverse Proxies konzipiert — was die Konfiguration entsprechend fragil macht.

	Zudem ist WOPI sicherheitsrelevant: Sofern nämlich Collabora in einem eigenen Docker-Container betrieben wird, muss dessen URL nach außen exponiert werden — andernfalls findet die Nextcloud "ihren" WOPI-Server nicht.		Zudem ist WOPI sicherheitsrelevant: Sofern nämlich Collabora in einem eigenen
			Docker-Container betrieben wird, muss dessen URL nach außen exponiert werden —
			andernfalls findet die Nextcloud "ihren" WOPI-Server nicht.
	Zwar lässt sich über die WOPI-Allowlist in Nextcloud steuern, welche IPs auf Dokumente		Zwar lässt sich über die WOPI-Allowlist in Nextcloud steuern, welche IPs auf Dokumente
	zugreifen dürfen. Jedoch gibt Collabora bei einem einfachen Aufruf von		zugreifen dürfen. Jedoch gibt Collabora bei einem einfachen Aufruf von
Zeile 142:		Zeile 144:
	----		----

	WOPI-Allowlist — warum sie existiert und was hineingehört ==		== WOPI-Allowlist — warum sie existiert und was hineingehört ==

	Nextcloud prüft bei jedem WOPI-Aufruf ob die anfragende IP in der Allowlist steht.		Nextcloud prüft bei jedem WOPI-Aufruf ob die anfragende IP in der Allowlist steht.
	Das verhindert dass ein beliebiger Server vorgeben kann, Collabora zu sein, und		Das verhindert dass ein beliebiger Server vorgeben kann, Collabora zu sein, und
	auf Dokumente zugreift.		auf Dokumente zugreift.

	=== Wo die Allowlist zu finden ist ===		=== Wo die Allowlist zu finden ist ===

	Im Nextcloud-Admin-Backend unter:		Im Nextcloud-Admin-Backend unter:
	''Einstellungen → Administration → Office''		''Einstellungen → Administration → Office''

	Dort findet sich das Feld „Zulässige IP-Adressen für WOPI-Anfragen". Alternativ		Dort findet sich das Feld „Zulässige IP-Adressen für WOPI-Anfragen". Alternativ
	per Kommandozeile:		per Kommandozeile:

	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	# Aktuellen Wert prüfen		# Aktuellen Wert prüfen
	docker exec nextcloud occ config:app:get richdocuments wopi_allowlist		docker exec nextcloud occ config:app:get richdocuments wopi_allowlist
	Wert setzen
	docker exec nextcloud occ config:app:set richdocuments wopi_allowlist		# Wert setzen
	--value="172.18.0.0/16"		docker exec nextcloud occ config:app:set richdocuments wopi_allowlist \
			--value="172.18.0.0/16"
	</syntaxhighlight>		</syntaxhighlight>

	=== Was eingetragen werden muss ===		=== Was eingetragen werden muss ===

	Die Allowlist akzeptiert '''nur IP-Adressen und CIDR-Blöcke''' — keine Hostnamen		Die Allowlist akzeptiert '''nur IP-Adressen und CIDR-Blöcke''' — keine Hostnamen
	oder URLs. Das ist bewusst so: DNS kann manipuliert werden, eine IP nicht.		oder URLs. Das ist bewusst so: DNS kann manipuliert werden, eine IP nicht.

	{\| class="wikitable"		{\| class="wikitable"
	! Szenario !! Was eingetragen ~~wirdCollabora~~ im selben Docker-Netzwerk-Collabora auf demselben Host, kein Docker-Collabora auf einem anderen Server mit fester IP-Collabora auf einem anderen Server mit dynamischer IP\|}		! Szenario !! Was eingetragen wird
			\|-
			\| Collabora im selben Docker-Netzwerk \|\| Das gesamte Docker-Subnetz, z.B. <code>172.18.0.0/16</code>. Damit ist die Allowlist unabhängig von IP-Verschiebungen einzelner Container.
			\|-
			\| Collabora auf demselben Host, kein Docker \|\| <code>127.0.0.1</code> (Loopback)
			\|-
			\| Collabora auf einem anderen Server mit fester IP \|\| Die feste IP des Collabora-Servers, z.B. <code>203.0.113.42</code>
			\|-
			\| Collabora auf einem anderen Server mit dynamischer IP \|\| Problematisch — siehe unten
			\|}

	=== Das DynDNS-Problem ===		=== Das DynDNS-Problem ===

	Läuft Collabora auf einem Server mit dynamischer IP (z.B. über einen DynDNS-Dienst),		Läuft Collabora auf einem Server mit dynamischer IP (z.B. über einen DynDNS-Dienst),
	ändert sich die IP regelmäßig. Da die Allowlist keine Hostnamen akzeptiert, müsste		ändert sich die IP regelmäßig. Da die Allowlist keine Hostnamen akzeptiert, müsste
	sie bei jeder IP-Änderung manuell aktualisiert werden.		sie bei jeder IP-Änderung manuell aktualisiert werden.

	Mögliche Lösungsansätze:		Mögliche Lösungsansätze:

	Einen Hoster mit fester IP wählen		* Einen Hoster mit fester IP wählen
	Einen Tunneldienst mit fester IP nutzen (z.B. Cloudflare Tunnel)		* Einen Tunneldienst mit fester IP nutzen (z.B. Cloudflare Tunnel)
	Collabora und Nextcloud auf demselben Server betreiben — dann greift		* Collabora und Nextcloud auf demselben Server betreiben — dann greift das Docker-Subnetz als stabiler CIDR-Block
	das Docker-Subnetz als stabiler CIDR-Block

	Für Heimserver-Setups wo Nextcloud und Collabora auf demselben Rechner laufen,		Für Heimserver-Setups wo Nextcloud und Collabora auf demselben Rechner laufen,
Zeile 182:		Zeile 202:

	== Häufige Fehlermeldungen und ihre Ursachen ==		== Häufige Fehlermeldungen und ihre Ursachen ==
	~~=== Was eingetragen werden muss ===~~

	~~Die Allowlist akzeptiert '''nur IP-Adressen und CIDR-Blöcke''' — keine Hostnamen~~
	~~oder URLs. Das ist bewusst so: DNS kann manipuliert werden, eine IP nicht.~~

	{\| class="wikitable"		{\| class="wikitable"
	! ~~Szenario~~ !! ~~Was eingetragen wird~~		! Fehlermeldung !! Ursache !! Fix
			\|-
			\| „Unautorisierter WOPI-Host" \|\| Collabora-IP nicht in Nextcloud-Allowlist \|\| WOPI-Allowlist auf Docker-Subnetz setzen
	\|-		\|-
	\| ~~Collabora im selben Docker~~-~~Netzwerk~~ \|\| ~~Das gesamte Docker-Subnetz, z.B.~~ <code>~~172.18.0.0/16~~</code>		\| <code>403 Forbidden</code> bei discovery \|\| Caddy-Regel blockiert Nextcloud \|\| <code>extra_hosts</code> prüfen, Caddy neu starten
	\|-		\|-
	\| Collabora ~~auf demselben Host, kein Docker~~ \|\| <code>~~127.0.0.1~~</code> ~~(Loopback)~~		\| „Failed to connect to remote server" \|\| Nextcloud erreicht Collabora extern statt intern \|\| <code>extra_hosts</code> in Nextcloud-compose korrigieren
	\|-		\|-
	\| Collabora ~~auf anderem Server, feste IP~~ \|\| ~~Die feste IP, z.B.~~ <code>~~203.0.113.42~~</code>		\| Dokument wird heruntergeladen statt geöffnet \|\| Collabora-MIME-Types nicht registriert \|\| <code>occ richdocuments:activate-config</code> ausführen
	\|-		\|-
	\| ~~Collabora auf anderem Server~~, ~~dynamische IP~~ \|\| ~~Problematisch~~ — ~~siehe unten~~		\| Admin-Test rot, Dokumente funktionieren \|\| Browser schickt keinen Referer \|\| Normal — Admin-Test ist kein verlässlicher Funktionstest
	\|}		\|}

	~~=== Das DynDNS-Problem ===~~

	----		----

Admin: /* Häufige Fehlermeldungen und ihre Ursachen */

2026-04-24T10:56:01Z

Häufige Fehlermeldungen und ihre Ursachen

← Nächstältere Version		Version vom 24. April 2026, 10:56 Uhr
Zeile 182:		Zeile 182:

	== Häufige Fehlermeldungen und ihre Ursachen ==		== Häufige Fehlermeldungen und ihre Ursachen ==
			=== Was eingetragen werden muss ===

			Die Allowlist akzeptiert '''nur IP-Adressen und CIDR-Blöcke''' — keine Hostnamen
			oder URLs. Das ist bewusst so: DNS kann manipuliert werden, eine IP nicht.

	{\| class="wikitable"		{\| class="wikitable"
	! ~~Fehlermeldung~~ !! ~~Ursache !! Fix~~		! Szenario !! Was eingetragen wird
	\|-		\|-
	~~\| „Unautorisierter WOPI-Host" \|~~\| Collabora-~~IP nicht in Nextcloud-Allowlist~~ \|\| ~~WOPI-Allowlist auf~~ Docker-Subnetz ~~setzen~~		\| Collabora im selben Docker-Netzwerk \|\| Das gesamte Docker-Subnetz, z.B. <code>172.18.0.0/16</code>
	\|-		\|-
	\| ~~<code>403 Forbidden</code> bei discovery \|\| Caddy-Regel blockiert Nextcloud~~ \|\| <code>~~extra_hosts~~</code> ~~prüfen, Caddy neu starten~~		\| Collabora auf demselben Host, kein Docker \|\| <code>127.0.0.1</code> (Loopback)
	\|-		\|-
	\| ~~„Failed to connect to remote server" \|\| Nextcloud erreicht~~ Collabora ~~extern statt intern~~ \|\| <code>~~extra_hosts~~</code> ~~in Nextcloud-compose korrigieren~~		\| Collabora auf anderem Server, feste IP \|\| Die feste IP, z.B. <code>203.0.113.42</code>
	\|-		\|-
	~~\| Dokument wird heruntergeladen statt geöffnet \|~~\| Collabora~~-MIME-Types nicht registriert \|\| <code>occ richdocuments:activate-config</code> ausführen~~		\| Collabora auf anderem Server, dynamische IP \|\| Problematisch — siehe unten
	\|-
	~~\| Admin-Test rot~~, ~~Dokumente funktionieren \|\| Browser schickt keinen Referer~~ \|\| ~~Normal~~ — ~~Admin-Test ist kein verlässlicher Funktionstest~~
	\|}		\|}

			=== Das DynDNS-Problem ===

	----		----

Admin: /* Was eingetragen werden muss */

2026-04-24T10:53:42Z

Was eingetragen werden muss

← Nächstältere Version		Version vom 24. April 2026, 10:53 Uhr
Zeile 163:		Zeile 163:
	oder URLs. Das ist bewusst so: DNS kann manipuliert werden, eine IP nicht.		oder URLs. Das ist bewusst so: DNS kann manipuliert werden, eine IP nicht.
	{\| class="wikitable"		{\| class="wikitable"
	! Szenario !! Was eingetragen wirdCollabora im selben Docker-Netzwerk-Collabora auf demselben Host, kein Docker-Collabora auf einem anderen Server mit fester IP-Collabora auf einem anderen Server mit dynamischer IP}		! Szenario !! Was eingetragen wirdCollabora im selben Docker-Netzwerk-Collabora auf demselben Host, kein Docker-Collabora auf einem anderen Server mit fester IP-Collabora auf einem anderen Server mit dynamischer IP\|}

	=== Das DynDNS-Problem ===		=== Das DynDNS-Problem ===
	Läuft Collabora auf einem Server mit dynamischer IP (z.B. über einen DynDNS-Dienst),		Läuft Collabora auf einem Server mit dynamischer IP (z.B. über einen DynDNS-Dienst),

Admin: /* WOPI-Allowlist — warum sie existiert */

2026-04-24T10:52:08Z

WOPI-Allowlist — warum sie existiert

← Nächstältere Version		Version vom 24. April 2026, 10:52 Uhr
Zeile 142:		Zeile 142:
	----		----

	== WOPI-Allowlist — warum sie existiert ==		WOPI-Allowlist — warum sie existiert und was hineingehört ==

	Nextcloud prüft bei jedem WOPI-Aufruf ob die anfragende IP in der Allowlist steht.		Nextcloud prüft bei jedem WOPI-Aufruf ob die anfragende IP in der Allowlist steht.
	Das verhindert dass ein beliebiger Server vorgeben kann, Collabora zu sein, und		Das verhindert dass ein beliebiger Server vorgeben kann, Collabora zu sein, und
	auf Dokumente zugreift.		auf Dokumente zugreift.
			=== Wo die Allowlist zu finden ist ===
			Im Nextcloud-Admin-Backend unter:
			''Einstellungen → Administration → Office''
			Dort findet sich das Feld „Zulässige IP-Adressen für WOPI-Anfragen". Alternativ
			per Kommandozeile:
	<syntaxhighlight lang="bash">		<syntaxhighlight lang="bash">
	# Aktuellen Wert prüfen		# Aktuellen Wert prüfen
	docker exec nextcloud occ config:app:get richdocuments wopi_allowlist		docker exec nextcloud occ config:app:get richdocuments wopi_allowlist
			Wert setzen
			docker exec nextcloud occ config:app:set richdocuments wopi_allowlist
			--value="172.18.0.0/16"
			</syntaxhighlight>
			=== Was eingetragen werden muss ===
			Die Allowlist akzeptiert '''nur IP-Adressen und CIDR-Blöcke''' — keine Hostnamen
			oder URLs. Das ist bewusst so: DNS kann manipuliert werden, eine IP nicht.
			{\| class="wikitable"
			! Szenario !! Was eingetragen wirdCollabora im selben Docker-Netzwerk-Collabora auf demselben Host, kein Docker-Collabora auf einem anderen Server mit fester IP-Collabora auf einem anderen Server mit dynamischer IP}
			=== Das DynDNS-Problem ===
			Läuft Collabora auf einem Server mit dynamischer IP (z.B. über einen DynDNS-Dienst),
			ändert sich die IP regelmäßig. Da die Allowlist keine Hostnamen akzeptiert, müsste
			sie bei jeder IP-Änderung manuell aktualisiert werden.
			Mögliche Lösungsansätze:

	~~# Gesamtes Docker-Subnetz erlauben~~ (~~empfohlen~~)		Einen Hoster mit fester IP wählen
	~~docker exec nextcloud occ config:app:set richdocuments wopi_allowlist \~~		Einen Tunneldienst mit fester IP nutzen (z.B. Cloudflare Tunnel)
	--~~value="172.18.0.0/16"~~		Collabora und Nextcloud auf demselben Server betreiben — dann greift
	~~</syntaxhighlight>~~		das Docker-Subnetz als stabiler CIDR-Block

	~~Das gesamte~~ Docker-Subnetz ~~statt einer einzelnen IP eintragen — dann ist die~~		Für Heimserver-Setups wo Nextcloud und Collabora auf demselben Rechner laufen,
	~~Allowlist unabhängig von IP-Verschiebungen einzelner Container nach einem Neustart~~.		ist das Problem irrelevant: das Docker-Subnetz ändert sich nicht.

	----		----

Admin: /* WOPI — Funktionsweise und Fallstricke */

2026-04-24T10:43:59Z

WOPI — Funktionsweise und Fallstricke

← Nächstältere Version		Version vom 24. April 2026, 10:43 Uhr
Zeile 10:		Zeile 10:
	diese Aufgabe beschreibt. Es wurde jedoch nie für selbst-gehostete Docker-Setups		diese Aufgabe beschreibt. Es wurde jedoch nie für selbst-gehostete Docker-Setups
	hinter Reverse Proxies konzipiert — was die Konfiguration entsprechend fragil macht.		hinter Reverse Proxies konzipiert — was die Konfiguration entsprechend fragil macht.

			Zudem ist WOPI sicherheitsrelevant: Sofern nämlich Collabora in einem eigenen Docker-Container betrieben wird, muss dessen URL nach außen exponiert werden — andernfalls findet die Nextcloud "ihren" WOPI-Server nicht.
			Zwar lässt sich über die WOPI-Allowlist in Nextcloud steuern, welche IPs auf Dokumente
			zugreifen dürfen. Jedoch gibt Collabora bei einem einfachen Aufruf von
			<code>https://collabora.beispiel.de/hosting/discovery</code>
			zahlreiche interne Konfigurationsdetails preis — Version, Build-Nummer, unterstützte
			Formate und Pfadstrukturen.

	----		----

Admin: /* WOPI — Funktionsweise und Fallstricke */

2026-04-24T10:34:37Z

WOPI — Funktionsweise und Fallstricke

← Nächstältere Version		Version vom 24. April 2026, 10:34 Uhr
Zeile 7:		Zeile 7:
	herunterzuladen.		herunterzuladen.

	Nextcloud und Collabora nutzen WOPI weil es das einzige offene Protokoll ist das		Nextcloud und Collabora nutzen WOPI, weil es das einzige offene Protokoll ist, das
	diese Aufgabe beschreibt. Es wurde jedoch nie für selbst-gehostete Docker-Setups		diese Aufgabe beschreibt. Es wurde jedoch nie für selbst-gehostete Docker-Setups
	hinter Reverse Proxies konzipiert — was die Konfiguration entsprechend fragil macht.		hinter Reverse Proxies konzipiert — was die Konfiguration entsprechend fragil macht.

Admin: /* Siehe auch */

2026-04-24T10:33:43Z

Siehe auch

← Nächstältere Version		Version vom 24. April 2026, 10:33 Uhr
Zeile 197:		Zeile 197:
	== Siehe auch ==		== Siehe auch ==

	* [[Hairpin-NAT – Collabora und Nextcloud hinter Caddy]] — das Netzwerkproblem hinter WOPI
	* [[Docker-Netzwerke und Container-IPs]] — IP-Pinning, extra_hosts, Backup-Checkliste
	* [[Caddy – Konzepte und Konfiguration]] — Reverse Proxy, Matcher, Firewall-Regeln		* [[Caddy – Konzepte und Konfiguration]] — Reverse Proxy, Matcher, Firewall-Regeln
			* [[Docker-Netzwerke und Container-IPs \| Docker-Netzwerke]] — IP-Pinning, extra_hosts, Backup-Checkliste
			* [[Hairpin-NAT – Collabora und Nextcloud hinter Caddy \| Hairpin-NAT]] — das Netzwerkproblem hinter WOPI

	----		----

Admin: /* Siehe auch */

2026-04-24T10:32:24Z

Siehe auch

← Nächstältere Version		Version vom 24. April 2026, 10:32 Uhr
Zeile 198:		Zeile 198:

	* [[Hairpin-NAT – Collabora und Nextcloud hinter Caddy]] — das Netzwerkproblem hinter WOPI		* [[Hairpin-NAT – Collabora und Nextcloud hinter Caddy]] — das Netzwerkproblem hinter WOPI
	* [[Docker-Netzwerke und Container-IPs~~\|Docker~~]] — IP-Pinning, extra_hosts, Backup-Checkliste		* [[Docker-Netzwerke und Container-IPs]] — IP-Pinning, extra_hosts, Backup-Checkliste
	* [[Caddy – Konzepte und Konfiguration]] — Reverse Proxy, Matcher, Firewall-Regeln		* [[Caddy – Konzepte und Konfiguration]] — Reverse Proxy, Matcher, Firewall-Regeln

Admin: /* Siehe auch */

2026-04-24T10:31:54Z

Siehe auch

← Nächstältere Version		Version vom 24. April 2026, 10:31 Uhr
Zeile 198:		Zeile 198:

	* [[Hairpin-NAT – Collabora und Nextcloud hinter Caddy]] — das Netzwerkproblem hinter WOPI		* [[Hairpin-NAT – Collabora und Nextcloud hinter Caddy]] — das Netzwerkproblem hinter WOPI
	* [[Docker-Netzwerke und Container-IPs ~~— Konfiguration und Fallstricke~~]] — IP-Pinning, extra_hosts, Backup-Checkliste		* [[Docker-Netzwerke und Container-IPs\|Docker]] — IP-Pinning, extra_hosts, Backup-Checkliste
	* [[Caddy – Konzepte und Konfiguration]] — Reverse Proxy, Matcher, Firewall-Regeln		* [[Caddy – Konzepte und Konfiguration]] — Reverse Proxy, Matcher, Firewall-Regeln