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.