fix: 🐛 🔧 Widen DB field uids for federated sharing - #5441

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

One more question though, is 255 long enough?

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

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.

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

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

lib/Migration/Version2060Date20200302131958.php

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 🙈

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.

@nickvergessen anything new?

In Talk we adjusted our table later with 255 user id length and 512 server url length

Then I'd suggest to also go with that (+1 for the @ separator in our case). Having a limit for URLs longer then 512 characters seems reasonable to me.