Slash in a user group ID breaks the member list

Describe the bug

Opening a user group whose ID contains a slash in the Groups section shows "There was an error fetching the member list" and an empty list. Groups without a slash are fine.

getUserGroupMembers() in src/services/userGroup.ts puts the group ID in a path segment:

const response = await axios.get(generateOcsUrl('/cloud/groups/{groupId}/users', { groupId }))

generateOcsUrl escapes the parameter, so a group ID of /dev goes on the wire as %2Fdev. Apache refuses encoded slashes in a path by default (AllowEncodedSlashes Off) and returns its own 404 before PHP ever runs.

That is not an exotic group ID. Keycloak asserts group paths, so user_oidc creates groups called /dev, /marketing and so on. On an SSO instance every provisioned group hits this and only the locally created ones work.

Server allows these IDs: createGroup() has no character restriction, and the provisioning routes are declared with 'requirements' => ['groupId' => '.+'], which is the deliberate opt-out of Symfony's default [^/]+ so that a group ID may contain a slash.

apps/settings does not have the problem because it encodes the value by hand before passing it to generateOcsUrl (apps/settings/src/store/users.js, the getUsers action), so it arrives double-encoded and gets past Apache. Contacts does not do that, which is why user management can show these groups and Contacts cannot.

Steps to reproduce

1. Create a group with a slash and add yourself to it (or let user_oidc/LDAP provision one, same result):

   occ group:add "/test"
   occ group:adduser "/test" alice
   

2. Log in as alice and open Contacts
3. Expand Groups in the left sidebar and click /test
4. The error toast appears, the member list stays empty

It also reproduces without the UI. The group does not even need to exist, since Apache answers before Nextcloud is reached:

$ curl -s -o /dev/null -w '%{http_code}\n' -H 'OCS-APIRequest: true' \
    https://cloud.example.com/ocs/v2.php/cloud/groups/test/users
401
$ curl -s -o /dev/null -w '%{http_code}\n' -H 'OCS-APIRequest: true' \
    https://cloud.example.com/ocs/v2.php/cloud/groups/%2Ftest/users
404
$ curl -s -o /dev/null -w '%{http_code}\n' -H 'OCS-APIRequest: true' \
    https://cloud.example.com/ocs/v2.php/cloud/groups/%252Ftest/users
401

401 means the request got to PHP. The 404 is Apache's own page (Server: Apache/2.4.68, Content-Type: text/html; charset=iso-8859-1), not an OCS response.

Expected behavior

The members of /test are listed, the same as for a group without a slash.

Actual behavior

Empty list and "There was an error fetching the member list". The console shows the 404 from getUserGroupMembers.

Contact version

8.7.4

Operating system

Debian, official nextcloud:34.0.1-apache image

PHP engine version

Other

Web server

Apache (supported)

Database

PostgreSQL

Additional info

PHP 8.5.8, Nextcloud 34.0.1, user_oidc 8.10.1.

This is a regression of #379, which was the same problem in the AngularJS UI and was fixed for 3.0.0.

#4603 is the same class in this app for vCard UIDs, and the suggestion there was to base64 the identifier in the path the way Calendar does. That would work here too and avoids the encoding question entirely.

One warning for anyone searching: #5418 has the identical message but comes from fetchCircleMembers and is a 429 from the circles regression. This one is the fetchUserGroupMembers branch in the same component and is a 404.

Copying the extra encodeURIComponent from settings would also fix it, but nextcloud/server#57364 is an open complaint about exactly that double encoding for group names containing spaces, so it may not be the direction you want.

Start in src/services/userGroup.ts at getUserGroupMembers(), then compare the request construction with the getUsers action in apps/settings/src/store/users.js. Reproduce the /test case and inspect the generated request and response; done means members of slash-containing groups load in Contacts without the 404 error.