[Bug]: new setting `show_federated_shares_to_trusted_servers_as_internal` returns options for federated shares in the internal section when searching for an email

[maximelehericy]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Context:

• federated setup (at least two instances)
• instances trust each other, and exchange their address book

As shown below, with the parameter show_federated_shares_to_trusted_servers_as_internal set to true, federated cloudId is possible in the External Share search input.

However, when I type an email in the Internal share section input to find the user with that email, I am returned with:

• one option for a federeted user,
• one for a federated group,
• one for the user matching the email

The options for federated user and federated group are unexpected.

Steps to reproduce

1. Have two nextcloud instances that trust each other and share their address book. Alice is on instance A, Bob on instance B.
2. Run php occ config:app:set files_sharing show_federated_shares_to_trusted_servers_as_internal --value true --type boolean
3. With Alice on instance A, input Bob's email address in the Internal Share field input.

Expected behavior

Only Bob's account from the synced address books should show up.

Nextcloud Server version

29

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

Related PR: #53661

[susnux]

But this is exactly what this option does no?
show_federated_shares_to_trusted_servers_as_internal should show federated shares to trusted servers as internal.
Thus if trusted servers are now listed in the internal section compared to untrusted which should end up in external shares.

[maximelehericy]

@susnux I am referring to what the search returns rather than where the share ends up once it is created.

The parameter show_federated_shares_to_trusted_servers_as_internal does two things where I expect it to do only one:

1. it puts a share to an account from a trusted server in the Internal share section, once the share is created. - that is expected
2. it adds matches for federated cloud IDs in the search results - that is unexpected

[susnux]

Well what it does is basically only one thing: It makes federated shares behave like internal shares.
So you do not need to create them below in external and then they suddenly move to the upper section - this would be unexpected to have them moved after creation.

Setting show_federated_shares_to_trusted_servers_as_internal is similar (with some restrictions) to just use global scale where federated shares are presented just like internal shares and the user should not see a difference.

[maximelehericy]

additional comment from my side:
with the trusted server thing [1], it is possible to request that servers exchange their account address book. From there, it is possible to search for an account on an other instance directly by typing an email address or a username. No need of a federated cloud ID.
This is why in our case it is useless and confusing for end-users to have matches for potential cloudIDs.

[1] https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/federated_cloud_sharing_configuration.html#configuring-trusted-nextcloud-servers

[nfebe]

it adds matches for federated cloud IDs in the search results - that is unexpected

No afaik, it adds matches for trusted federated cloud Ids, not just any cloud id. From the screenshot all the servers shown are different domains. So I am not sure why it is unexpected.

show_federated_shares_to_trusted_servers_as_internal does what it is supposed to do, but I think the definition is being streched to treat_federated_shares_to_trusted_servers_as_internal. It is not exactly the same.

Federated shares are still federated shares and we don't know if implementing small things like this that gradually turns one flag to mean another thing is generally going to be accepted behavior for most users or if its the direction we are intentionally trying to take.

This is feature request-ish.

cc: @marcoambrosini @jancborchardt any product or design opinions on this?

[susnux]

@nfebe no it is a bug @maximelehericy showed me the problem on a test instance where only show_federated_shares_to_trusted_servers_as_internal was set.

In this case only trusted federated servers should show up in:

1. The share list with internal
2. In search results with internal

But when show_federated_shares_to_trusted_servers_as_internal is set (NOT show_federated_shares_as_internal), then if you search for an email address in the internal share search box, then it also shows (non existing) possible federated cloud ids as suggestions in the internal section.

So the problem:

• If show_federated_shares_to_trusted_servers_as_internal is set
• but not show_federated_shares_as_internal
• AND you configured federation with a TRUSTED server (to share the account list)

Then you try to search for a FEDERATED user using its EMAIL address in the INTERNAL share section.

Expected:

• Only see the federated user with that cloud id

Current behavior:

• you get the federated user with the correct email address ✅
• you also get a suggestion for a non existing, non trusted possible federated user with this email address as cloud id ❌

Meaning you type name@mail.example.com you expect only a federated user with that mail address, but you also get a suggestion for user name on instance mail.example.com which is not a trusted server and not existing (e.g. the user would be name on cloud.example.com but with that email address).

[maximelehericy]

@susnux @nfebe I recently discovered that synced address books from trusted servers only sync usernames and displaynames, but not emails. So email matching in search only works with internal users and users from a lookup server. (the latter is the case in our context).
This does not influence the bug described above (searching for an email will show a potential non-existing federated cloudId).
If you test only with synced address books from trusted servers (and w/o lookup server), it will influence the results however... do not expect a match upon email for a remote user.