fix(wopi): stable guest UserId and correct IsAnonymousUser for named guests

[Arildm-no]

Problem

Two bugs in WopiController::checkFileInfo() prevent cursor presence from working when a named guest edits a document via a public link alongside a logged-in user.

Bug 1 — Guest UserId is randomly generated on every WOPI call

// Before (broken)
$guestUserId = 'Guest-' . \OCP\Server::get(\OCP\Security\ISecureRandom::class)->generate(8);

The WOPI protocol requires UserId to be stable for the duration of a session. Collabora calls CheckFileInfo multiple times (e.g. on token refresh), and each call returned a different random ID for the same guest. Collabora treats each new ID as a new user, breaking cursor tracking and view presence entirely.

Bug 2 — IsAnonymousUser is unconditionally true for all public link users

// Before (broken)
if ($isPublic) {
    $response['IsAnonymousUser'] = true; // set even when guest has a display name
}

Collabora interprets IsAnonymousUser = true as a privacy signal and hides that user's cursor from other editors. This is correct for a truly anonymous viewer (no name entered), but wrong for a guest who has explicitly entered a display name in the Nextcloud sharing prompt.

Fix

1. Derive UserId deterministically from the WOPI token using SHA-256, so the same guest token always maps to the same identity within a session.
2. Only set IsAnonymousUser = true when the guest has no display name. Named guests get false, enabling cursor visibility.

// After
$guestUserId = 'Guest-' . substr(hash('sha256', $wopi->getToken()), 0, 8);

$response['IsAnonymousUser'] = empty($wopi->getGuestDisplayname());

Steps to reproduce

1. Share a document with a public edit link
2. Open the document as a logged-in admin
3. Open the public link in another browser / incognito window, enter a name when prompted
4. Both users type — the logged-in user cannot see the guest's cursor or writing indicator

Expected behaviour

Named guests have a visible, coloured cursor indicator, just like any other named collaborator.

Tested on

• Nextcloud 33
• richdocuments 10.1.2
• Collabora Online CODE 25.04.9.4

[joshtrichards]

Good catch! Makes sense.

I'm surprised I can't find any open bug reports on this topic.

Anyhow, from my end, as noted, I'd just like to see the output bumped up from the hash.

P.S. #2170 impacts this too (I assume). But that's not guest specific - and, more importantly, this is still a good improvement. And, presumably guests will likely also benefit from whatever eventually targets #2170 anyhow (by virtue of this change).

[Arildm-no]

Thanks for the thorough review, @joshtrichards! Both requested changes have been applied:

• Hash length bumped to 16 chars in both checkFileInfo() and getSettings() — good call on the Birthday Paradox mitigation, 64-bit is clearly the right default here.
• Rebased onto current main — resolved the conflict with the $isVersion public-link guard that was added upstream; both changes coexist cleanly.

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[Arildm-no]

Added Signed-off-by to both commits to address the DCO requirement. Hash length was already bumped to 16 chars in the previous update. Should be good for review now.