WOPI integration

[brandon-doornbos]

This PR adds WOPI integration to Copyparty, mainly from a Collabora Online perspective (hit me up if you tested other impls that didn't work). See below how it should work.

Screencast_20260523_230350.webm

Adds an option to enable WOPI and to specify the WOPI client (e.g. self-hosted Collabora Online). The client is by default set to the EU demo server of Collabora themselves, which you can use if you access your Copyparty through a publicly accessible URL (so Collabora can actually get your file).

WOPI expects a file-id and access-token for each session, we implement this through the default file-key generation and salt for file-id and through a (os) random salt (re-generated on every document open) on the username for access-token. These then get stored in a dictionary in the http server to re-authenticate only that specific combination of file-key and access-token.

(Future) TODOs:

• Access-token expiration and delete from dictionary
• Extra WOPI methods/options?
• More config options (extensions to allow WOPI for, etc.)?
• Granular access control (we now just bail if you can't edit, but WOPI has stuff for only viewing etc.)

This PR complies with the DCO; https://developercertificate.org/

[icxes]

related issue #423

[brandon-doornbos]

Since this adds another way of authenticating, if someone else could check my logic would be nice :). Let me know if I need to change things or if this isn't appropriate for the project.

If it's close I'll start on documentation in the readme.

Demo WOPI client btw: https://demo.eu.collaboraonline.com

[i0nicle]

would b awesome if this got merged B) would replace my seafile + collabora setup

[9001]

haven't had a chance to look at this yet and will probably be a while still, but wanted to mention something right away --

copyparty does not and will never have support for locking files or folders, will never any sort of file locking at all -- this is an intentinoal choice because the complications and safety implications of having to ensure that such locks behave correctly is not something I want to maintain or guarantee

so if that could be a problem then maybe this is a bad idea , I just recall someone saying wopi would expect correct locking behavior

[brandon-doornbos]

Thanks for the heads-up, I'll put it in the documentation for other implementations. For Collabora anyway, this actually has handling on their side, although I'll look at properly handling it from our side. (edit, should be done, see 8304388)