fix: 🐛 🔧 Widen DB field uids for federated sharing

[moodyjmz]

Uids in several fields are not long enough for names, this shifts length 64 >>>255

• Resolves: #
• Target version: main

Summary

When a federated cloud ID exceeds 64 characters, the owner_uid and editor_uid columns in the oc_richdocuments_wopi table silently truncate the value. This can prevent federated users from opening documents in Collabora.

This PR adds a database migration to widen owner_uid and editor_uid from varchar(64) to varchar(255), aligning them with the maximum length of a federated cloud ID (user@remote).

Background

The oc_richdocuments_wopi table stores active Collabora editing sessions. The owner_uid column identifies the file owner and editor_uid identifies the current editor. In a federation context, these values may contain a full cloud ID in the format user@remote.domain, which can easily exceed 64 characters with longer usernames or domain names.

The columns were originally defined as varchar(64) in Version2060Date20200302131958, which matches the local Nextcloud user ID limit but does not account for federated cloud IDs.

Changes

New migration: Version10100Date20260226000000

• Widens owner_uid from varchar(64) to varchar(255) on oc_richdocuments_wopi
• Widens editor_uid from varchar(64) to varchar(255) on oc_richdocuments_wopi
• Includes guard checks to only alter columns if they are below the target length
• Returns null (no-op) if the table or columns do not exist or are already the correct size

Affected table

Table	Column	Before	After
oc_richdocuments_wopi	owner_uid	varchar(64)	varchar(255)
oc_richdocuments_wopi	editor_uid	varchar(64)	varchar(255)

Notes

• The uid columns in oc_richdocuments_direct and oc_richdocuments_assets are also varchar(64) but currently only store local user IDs ($this->userId), so they are not affected by this issue. They can be addressed separately if needed.
• The original migration (Version2060Date20200302131958) could also be updated to use varchar(255) for these columns so that fresh installations get the correct size immediately.

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Documentation (manuals or wiki) has been updated or is not required

[moodyjmz]

@juliusknorr I am not sure if we should make this change into the original migration file too. Also I am not sure about backporting.

[moodyjmz]

One more question though, is 255 long enough?

[juliusknorr]

One more question though, is 255 long enough?

That is what I've seen talk and files using. @nickvergessen @ArtificialOwl do you have any further insights there? Technically the federated cloud id could be longer then 255 characters if you are using a long domain name.

https://github.com/nextcloud/spreed/blob/b5d2a951863852f25ffe6aca2f43f8881288b570/lib/Migration/Version19000Date20240214095011.php#L39
https://github.com/nextcloud/server/blob/7e264ba58e73349f9696dd9c6c96a283ab5c7a6c/apps/files_sharing/lib/Migration/Version11300Date20201120141438.php#L50
https://github.com/nextcloud/server/blob/7e264ba58e73349f9696dd9c6c96a283ab5c7a6c/apps/contactsinteraction/lib/Migration/Version010000Date20200304152605.php#L50

[juliusknorr]

I am not sure if we should make this change into the original migration file too. Also I am not sure about backporting.

Yes, we can backport this as the tables have only temporary entires so even on larger scale systems the backported migration would not cause longer downtimes on schema changes). For the backporting process i can guide you through it.

Chaning the size in the original migration as well will be faster on initial installations as then only the first one would need to run and the others can be skipped. Less db operations to get the schema setup initially.

[moodyjmz]

from what I see, the length of the UID can be 64

server/lib/public/IUser.php:24

public const MAX_USERID_LENGTH = 64;

and the max for a domain is 253

So, could be 318... I think - just to be clear = adding the @ sign to get to 318

[moodyjmz]

@juliusknorr So I should update the original migration file here as well?

lib/Migration/Version2060Date20200302131958.php

[nickvergessen]

from what I see, the length of the UID can be 64
server/lib/public/IUser.php:24
public const MAX_USERID_LENGTH = 64;
and the max for a domain is 253
So, could be 318... I think - just to be clear = adding the @ sign to get to 318

That is with the assumpts that:

• Nextcloud is not installed in a subfolder
• It's only Nextclouds other OCM (Open Cloud Mesh) could have longer user ids

In Talk we adjusted our table later with 255 user id length and 512 server url length:
https://github.com/nextcloud/spreed/blob/c8c21215af6474536de9c10a0f3d3906e4cc1fc8/lib/Migration/Version18000Date20231024141627.php#L39-L58

But inviter_cloud_id we still have at 255 🙈

[moodyjmz]

from what I see, the length of the UID can be 64
server/lib/public/IUser.php:24
public const MAX_USERID_LENGTH = 64;
and the max for a domain is 253
So, could be 318... I think - just to be clear = adding the @ sign to get to 318

That is with the assumpts that:

• Nextcloud is not installed in a subfolder
• It's only Nextclouds other OCM (Open Cloud Mesh) could have longer user ids

In Talk we adjusted our table later with 255 user id length and 512 server url length: https://github.com/nextcloud/spreed/blob/c8c21215af6474536de9c10a0f3d3906e4cc1fc8/lib/Migration/Version18000Date20231024141627.php#L39-L58

But inviter_cloud_id we still have at 255 🙈

Ok

So I assumed the UID would be limited by the const at 64 and probably validated against that somewhere

and the domain length limited by DNS spec - without folders

I was incorrect in my assumptions.

Looking at the code:

$remoteServer Data Flow - DocumentController.php line 241 — the remote() method parameter

So $remoteServer looks like the initiator's own absolute URL — generated by IURLGenerator::getAbsoluteURL('/'). That returns the full base URL of the Nextcloud instance, which would include subfolders if installed in one (e.g. https://example.com/nextcloud/).

remoteServer Data Flow

No length validation exists anywhere in this chain.

1. lib/Service/FederationService.php:203 — getRemoteRedirectURL() generates the initiator's own base URL via $this->urlGenerator->getAbsoluteURL('/') and stores it in $initiatorServer. This is the full URL of the Nextcloud instance where the user is browsing, including any subfolder path (e.g. https://example.com/nextcloud/).

2. lib/Service/FederationService.php:217 — $initiatorServer is included as the remoteServer query parameter in a redirect URL that sends the user's browser to the source server (the server that owns the file).

3. lib/Controller/DocumentController.php:241 — The source server's remote() controller method receives $remoteServer directly from the query string. No sanitisation or length check is performed.

4. lib/Controller/DocumentController.php:268-272 — The source server calls getRemoteFileDetails() to fetch the initiator's WOPI token details via API, then passes $remoteServer unchanged to upgradeToRemoteToken().

5. lib/TokenManager.php:139-143 — upgradeToRemoteToken() builds the federated cloud ID by concatenating $remoteWopi->getEditorUid() . '@' . $remoteServer and writes it to guestDisplayname (varchar(255)) via $wopi->setGuestDisplayname(). The same $remoteServer is also stored separately in $wopi->setRemoteServer().

Point of failure

The truncation occurs on the source server (the one that owns the file), not the initiator. When the source server's remote() controller calls upgradeToRemoteToken(), the values are written to the source server's richdocuments_wopi table. The database silently truncates editor_uid (varchar(64)) and guestDisplayname (varchar(255)) without raising an error. Downstream code then operates on corrupted cloud IDs, causing the document open to fail.

So 512 could also fail - unlikely, as the path is unlikely to be that long, but it could. The 255 or 512 are irrelevant, it could be 513, at which point it fails.