Disable 'Allow users on this server to send shares to other servers' option has not a right behaviour

[davitol]

Steps to reproduce

1. Enable option Allow users on this server to send shares to other servers
2. Send a file to a user of another server
3. Disable this option in server 'A'.

Expected behaviour

The file in server B should not appear

Actual behaviour

File in server B still appearing and if you click on it, nothing seems to happen, but 500 internal Server error occurs

Server configuration

Operating system: ubuntu 14.04

Web server: apache 2.4.7

Database: mysql

PHP version: 5.5.9

ownCloud version: version":"8.1.0.5","versionstring":"8.1 beta 1","edition":"Enterprise"

Updated from an older ownCloud or fresh install: Fresh install

List of activated apps:
Enabled:

• activity: 1.2.3
• admin_audit: 0.6
• encryption: 1.0.0
• enterprise_key: 0.1.0
• files: 1.1.9
• files_locking:
• files_pdfviewer: 0.7
• files_sharing: 0.6.1
• files_sharing_log: 0.5
• files_texteditor: 0.4
• files_trashbin: 0.6.2
• files_versions: 1.0.5
• files_videoviewer: 0.1.3
• firewall: 0.91.2
• firstrunwizard: 1.1
• gallery: 0.6.0
• provisioning_api: 0.2
• templateeditor: 0.1
• updater: 0.4
• user_ldap: 0.6.0
• windows_network_drive: 0.1.1

Are you using external storage, if yes which one: no

Are you using encryption: yes

Are you using an external user-backend, if yes which one: ActiveDirectory

Client configuration

Browser: Internet Explorer 9 & Firefox

[PVince81]

The first thought I had was to delete the existing shares whenever the admin disables "allow users to send shares". But the problem is that they might be link shares (which are still allowed).
There is always the risk of the admin clicking on the wrong checkbox and then the shares would be gone.

The second option which is probably better and quicker to fix is to fix the 500 to actually be a 404. The second server should find out that the shares do not exist any more (even though they might still in the database on server A)

[PVince81]

Hmm looks like the other option "allow users to receive shares" also does not remove the mount points.

[PVince81]

We have a checkbox in the admin page called "Allow users on this server to send shares to other servers".
When disabling it, public.php/webdav becomes unavailable, as it is usually used for such shares.

I think we have some kind of conflict here.
Ideally the public webdav should always be available for the previews (it is used by text previews #16464) and also the future WebDAV work (#12353), however we also need a way to prevent external servers to connect to existing remote shares after the admin has disabled remote sharing (see #16439).

Now remote sharing is even more complicated because it has two ways:

1. Sending the share directly by typing a remote address in the share dropdown
   or
2. Creating a link share and letting other people add it to their ownClouds

In an ideal case, disabling "Allow users on this server to send shares to other servers" should block both cases. But we cannot just block the WebDAV part of the link share but still allow the web UI to work, this is inconsistent.

We need to think about better ways.

Remote share mount points also uses "shareinfo.php", maybe we could only block on that ? But it means that if people got the idea of mounting public.php/webdav using other tools, they would still have access.

Yet another idea would be to delete the remote shares (but not the link shares!) whenever the admin disables sending remote shares. But that doesn't seem to prevent public.php/webdav access.

@oparoz @DeepDiver1975 @schiesbn @icewind1991 any ideas ?

[PVince81]

Here is a short term fix #16465, but this is only to prevent the 500 error on the connecting server and have it detect that the share is not available any more.

[PVince81]

If an admin wants to really avoid remote mounting, they should disable both "public link" and "allow sharing with remote users".

[MorrisJobke]

@PVince81 Can this be closed now?

[PVince81]

Ok, then let's continue the discussion here: #16464 (that tickets illustrates better what is wrong with our API)