If a user accepts a federated share from a network which his server cannot reach, the user gets blocked. #23792

SergioBertolinSG · 2016-04-05T07:19:48Z

Steps to reproduce:

Having two servers, one accessible via Internet, with public domain called ServerPublic and a server in a private network not accessible from the outside called ServerPrivate do:

User1 from ServerPrivate (which has done login at least once), shares using federated sharing a file with User2 from ServerPublic.
User2, accepts the federated share coming from User1 in ServerPrivate.

Expected behaviour:

An error or warning, since the share is not accesible.

Actual behaviour

User2 gets blocked, the files view gets loading forever and if trying to login with another browser the user cannot login.

Server configuration

Operating system:
Ubuntu 14.04

Web server:
Apache

Database:
MySQL

PHP version:
5.5.9

ownCloud version: (see ownCloud admin page)
{"installed":true,"maintenance":false,"version":"9.0.1.1","versionstring":"9.0.1 RC1","edition":"Enterprise"}

Updated from an older ownCloud or fresh install:
Fresh

The content of config/config.php:

Are you using external storage, if yes which one: local/smb/sftp/...
No

Are you using encryption:
No.

Logs

{"reqId":"Qew2FhsisovMSZjLk+ke","remoteAddr":"HIDDEN_IP","app":"core","message":"Trusted domain error. \"HIDDEN_IP\" tried to access using \"SERVERPUBLIC_HOST\" as host.","level":2,"time":"2016-04-05T06:53:55+00:00","method":"GET","url":"\/","user":"--"}
{"reqId":"pdCqPQlDvbsC9IZBT8VV","remoteAddr":"HIDDEN_IP","app":"core","message":"Trusted domain error. \"HIDDEN_IP\" tried to access using \"SERVERPUBLIC_HOST\" as host.","level":2,"time":"2016-04-05T06:53:55+00:00","method":"GET","url":"\/index.php\/core\/js\/oc.js?v=79e2c52611b615699a79f992a1f8141e","user":"--"}
{"reqId":"sRG0ILaahIto24bhVda1","remoteAddr":"HIDDEN_IP","app":"core","message":"Trusted domain error. \"HIDDEN_IP\" tried to access using \"SERVERPUBLIC_HOST\" as host.","level":2,"time":"2016-04-05T06:53:55+00:00","method":"GET","url":"\/cron.php","user":"--"}

Client configuration

browser
Chrome, Firefox.

The text was updated successfully, but these errors were encountered:

schiessle · 2016-04-05T08:01:31Z

I can't reproduce it, steps I tried with master:

login at server1
share file from server1 to server2
make server1 unaccessible by renaming the root folder of the server
login at server2
accept share

Result:

No error message (which could be improved) but server2 stays usable. Everytime I refresh the file list I only see in the owncloud.log:

{"reqId":"tb6bcWs28A7gGewvYeZ+","remoteAddr":"127.0.0.1","app":"core","message":"Exception while scanning storage \"shared::16a357b86b252b4c833619c8735e4a76\": Sabre\\HTTP\\ClientHttpException: Method Not Allowed","level":3,"time":"2016-04-05T07:57:06+00:00","method":"PROPFIND","url":"\/master\/remote.php\/webdav\/","user":"schiesbn"}

As soon as I restore server1 the error message is gone and the share become visible.

schiessle · 2016-04-05T08:02:04Z

@rullzer can you try to reproduce it? Thanks!

SergioBertolinSG · 2016-04-05T08:05:33Z

I guess the problem is that it keeps trying to access the network while not finding it, I've seen it having a virtual machine with a server inside (private server) and the public server is our docker server.

rullzer · 2016-04-05T08:12:23Z

I can't reproduce here at the moment. But I think the issue is that there is no response. So no 200, no 503, no 404 etc. So stuff just hangs.

I agree we should solve this but I don't think it is such a big issue. If you do weird setups like this you can expect trouble.

I also don't think it is sev2

schiessle · 2016-04-05T08:15:51Z

Basically there are three things which happen in the background once you accept a share:

We send a accept message back to the original server so that it can be shown in the activities.
The server gets added as trusted server and we try to create a relationship between the two servers
We try to mount the storage

But both http request (1 and 2) should just time out. For 1. the notification will be lost. 2. will be tried again later. Mounting a storage which is not available should result in the error message I posted above and shouldn't block the server.

I agree with @rullzer that it might be something related response of the server. But every http request should time out and shouldn't make the complete server useless.

schiessle · 2016-04-19T09:03:38Z

Tried once more as discussed with @SergioBertolinSG

My steps:

setup ServerPrivate in vm
setup ServerPublic on my dev system
create federated share from ServerPrivate to ServerPublic
shutdown vm -> serverPrivate is no longer available
login at ServerPublic
accept share

same result as here: #23792 (comment) Everything works fine

schiessle · 2016-04-19T09:05:18Z

Downgrade severity because it is a really special corner case. Added "need info" label because I still couldn't find a way to re-produce it

SergioBertolinSG · 2016-04-20T07:17:44Z

setup ServerPrivate in vm

setup ServerPublic on my dev system

create federated share from ServerPrivate to ServerPublic

shutdown vm -> serverPrivate is no longer available

login at ServerPublic

accept share

Step 4 is not needed. The VM has to be running.

The problem is that servers are in different networks, from private to public you can create the share, but not vice versa, same happens with accepting shares and it is not well handled.

PVince81 · 2016-09-20T09:44:26Z

Is this still happening with 9.0.5 ?

PVince81 · 2016-12-08T18:33:15Z

@SergioBertolinSG please retest.

SergioBertolinSG · 2016-12-09T09:00:53Z

Still happening in stable9.1.

SergioBertolinSG · 2016-12-09T09:05:57Z

I think this is high, because the user gets totally blocked, and the situation doesn't feel so corner, someone can have an oC server in a private network and share using federation to a public server. Perhaps the user doesn't notice that their servers are in different networks and accidentally blocks the user who recieves it.

PVince81 · 2016-12-09T09:07:54Z

Indeed... I can't think of a good solution yet.

How long is the user totally blocked ? I'd suspect that after a timeout of a minute or so the connection to the federated share will abort. And then it should cache the fact that it failed somewhere so that it doesn't retry too often.

SergioBertolinSG · 2016-12-09T09:25:23Z

Not really, it takes several minutes. Feels like it is totally broken, after successfully login everything goes extremely slow, not usable at all. Also, if you log out and in again it takes those minutes again.

PVince81 · 2016-12-09T09:26:27Z

Ok, thanks for the details. So it means there is indeed a timeout in place, but ownCloud doesn't remember that it failed. Will have to check the "remote status" caching, I seem to remember that we have that...

PVince81 · 2016-12-12T16:21:29Z

Steps to reproduce easily

Create two users "user1" and "user2" on the same instance
Login as "user2"
Create a folder "test"
Share "test" with "user1@localhost" using federated sharing
Login as "user1"
Accept the share
Go to the "oc_share_external" table and change the column "remote" to an IP address in the current network that hangs when doing curl against. In my case: "http://192.168.1.3/owncloud" did the trick
Refresh the page as "user1"

Everything is very slow.

PVince81 · 2016-12-12T16:36:32Z

This will improve the situation but not enough: #26791
Basically the problem is that the exception wasn't properly caught when calling getPermissions(), so the storage was never marked as "unavailable".

But now I see that even when marked unavailable, there are still code paths that will try to connect to verify if it is actually still unavailable... Need to fix it to respect the 10 minutes buffer.

PVince81 · 2016-12-12T16:50:43Z

PR here #26817 which is #26791 plus some additional changes.

Now what I don't understand is why it's still slow even though it doesn't go through the code path that will actually contact the remote server. Maybe there are some other code paths I don't know about...

PVince81 · 2016-12-12T16:54:46Z

Arghh, found it... bypasses the availability wrapper:

0  OC\Http\Client\Client->get() /srv/www/htdocs/owncloud/lib/private/Http/Client/Client.php:135
1  OCA\FederatedFileSharing\DiscoveryManager->discover() /srv/www/htdocs/owncloud/apps/federatedfilesharing/lib/DiscoveryManager.php:94
2  OCA\FederatedFileSharing\DiscoveryManager->getWebDavEndpoint() /srv/www/htdocs/owncloud/apps/federatedfilesharing/lib/DiscoveryManager.php:133
3  OCA\Files_Sharing\External\Storage->__construct() /srv/www/htdocs/owncloud/apps/files_sharing/lib/External/Storage.php:83
4  OC\Files\Storage\StorageFactory->getInstance() /srv/www/htdocs/owncloud/lib/private/Files/Storage/StorageFactory.php:82
5  OC\Files\Mount\MountPoint->createStorage() /srv/www/htdocs/owncloud/lib/private/Files/Mount/MountPoint.php:137
6  OC\Files\Mount\MountPoint->getStorage() /srv/www/htdocs/owncloud/lib/private/Files/Mount/MountPoint.php:160
7  OC\Files\Config\UserMountCache->OC\Files\Config\{closure}() /srv/www/htdocs/owncloud/lib/private/Files/Config/UserMountCache.php:91
8  array_filter()  /srv/www/htdocs/owncloud/lib/private/Files/Config/UserMountCache.php:92
9  OC\Files\Config\UserMountCache->registerMounts() /srv/www/htdocs/owncloud/lib/private/Files/Config/UserMountCache.php:92
10 OC\Files\Config\MountProviderCollection->registerMounts() /srv/www/htdocs/owncloud/lib/private/Files/Config/MountProviderCollection.php:133
11 OC\Files\Filesystem::initMountPoints() /srv/www/htdocs/owncloud/lib/private/Files/Filesystem.php:446
12 OC\Files\Filesystem::init() /srv/www/htdocs/owncloud/lib/private/Files/Filesystem.php:373
13 OC_Util::setupFS() /srv/www/htdocs/owncloud/lib/private/legacy/util.php:231
14 OCA\DAV\Connector\Sabre\Auth->auth() /srv/www/htdocs/owncloud/apps/dav/lib/Connector/Sabre/Auth.php:228
15 OCA\DAV\Connector\Sabre\Auth->check() /srv/www/htdocs/owncloud/apps/dav/lib/Connector/Sabre/Auth.php:146
16 Sabre\DAV\Auth\Plugin->beforeMethod() /srv/www/htdocs/owncloud/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php:163
17 call_user_func_array:{/srv/www/htdocs/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105}() /srv/www/htdocs/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105
18 Sabre\Event\EventEmitter->emit() /srv/www/htdocs/owncloud/3rdparty/sabre/event/lib/EventEmitterTrait.php:105
19 Sabre\DAV\Server->invokeMethod() /srv/www/htdocs/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:446
20 Sabre\DAV\Server->exec() /srv/www/htdocs/owncloud/3rdparty/sabre/dav/lib/DAV/Server.php:248
21 require_once()  /srv/www/htdocs/owncloud/apps/dav/appinfo/v1/webdav.php:56
22 {main}          /srv/www/htdocs/owncloud/remote.php:164

That one would go faster if you have memcache enabled because the server status info is stored there.

PVince81 · 2016-12-12T16:59:41Z

The problem is that it connects to the remote server in the storage constructor even though we might not need that storage at all. We need to move that call to be in the DAV storage's init() method which is only called when an actual call is made.

PVince81 · 2016-12-12T17:04:32Z

Okay, I've moved the discover manager call to be in init() in this PR #26817, apparently this speeds up a lot now.

However, note that every 10 minutes the storage will be rechecked so there might be temporary slow downs.

PVince81 · 2017-11-08T19:24:24Z

should work fine on OC 10.0.4: #29314

lock · 2019-07-30T17:01:24Z

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

SergioBertolinSG added Type:Bug sev2-high feature:federated-cloud-sharing labels Apr 5, 2016

SergioBertolinSG added this to the 9.0.1-current-maintenance milestone Apr 5, 2016

SergioBertolinSG modified the milestones: 9.0.2-next-maintenance, 9.0.1-current-maintenance Apr 6, 2016

schiessle added sev3-medium needs info and removed sev2-high labels Apr 19, 2016

PVince81 modified the milestones: 9.0.3-next-maintenance, 9.0.2-current-maintenance Apr 19, 2016

PVince81 modified the milestones: 9.0.4-next-maintenance, 9.0.3-current-maintenance Jun 2, 2016

PVince81 modified the milestones: 9.0.5, 9.0.4 Jul 18, 2016

PVince81 modified the milestones: 9.0.6, 9.0.5 Sep 21, 2016

PVince81 modified the milestones: 9.0.7, 9.0.6 Oct 20, 2016

PVince81 modified the milestones: 9.2, 9.0.7 Nov 30, 2016

PVince81 assigned SergioBertolinSG Dec 8, 2016

PVince81 unassigned SergioBertolinSG Dec 9, 2016

PVince81 added sev2-high and removed needs info sev3-medium labels Dec 9, 2016

PVince81 self-assigned this Dec 9, 2016

PVince81 mentioned this issue Dec 12, 2016

[debug] Stable9.1 fed share lag test #26817

Closed

PVince81 modified the milestones: triage, 10.0 May 15, 2017

PVince81 removed their assignment Jun 26, 2017

PVince81 closed this as completed Nov 8, 2017

felixboehm removed this from the triage milestone Apr 10, 2018

lock bot locked as resolved and limited conversation to collaborators Jul 30, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

If a user accepts a federated share from a network which his server cannot reach, the user gets blocked. #23792

If a user accepts a federated share from a network which his server cannot reach, the user gets blocked. #23792

SergioBertolinSG commented Apr 5, 2016 •

edited by DeepDiver1975

schiessle commented Apr 5, 2016

schiessle commented Apr 5, 2016

SergioBertolinSG commented Apr 5, 2016

rullzer commented Apr 5, 2016

schiessle commented Apr 5, 2016

schiessle commented Apr 19, 2016

schiessle commented Apr 19, 2016

SergioBertolinSG commented Apr 20, 2016 •

edited

PVince81 commented Sep 20, 2016

PVince81 commented Dec 8, 2016

SergioBertolinSG commented Dec 9, 2016

SergioBertolinSG commented Dec 9, 2016

PVince81 commented Dec 9, 2016

SergioBertolinSG commented Dec 9, 2016

PVince81 commented Dec 9, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Nov 8, 2017

lock bot commented Jul 30, 2019

If a user accepts a federated share from a network which his server cannot reach, the user gets blocked. #23792

If a user accepts a federated share from a network which his server cannot reach, the user gets blocked. #23792

Comments

SergioBertolinSG commented Apr 5, 2016 • edited by DeepDiver1975

Steps to reproduce:

Expected behaviour:

Actual behaviour

Server configuration

Client configuration

schiessle commented Apr 5, 2016

schiessle commented Apr 5, 2016

SergioBertolinSG commented Apr 5, 2016

rullzer commented Apr 5, 2016

schiessle commented Apr 5, 2016

schiessle commented Apr 19, 2016

schiessle commented Apr 19, 2016

SergioBertolinSG commented Apr 20, 2016 • edited

PVince81 commented Sep 20, 2016

PVince81 commented Dec 8, 2016

SergioBertolinSG commented Dec 9, 2016

SergioBertolinSG commented Dec 9, 2016

PVince81 commented Dec 9, 2016

SergioBertolinSG commented Dec 9, 2016

PVince81 commented Dec 9, 2016

PVince81 commented Dec 12, 2016

Steps to reproduce easily

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Dec 12, 2016

PVince81 commented Nov 8, 2017

lock bot commented Jul 30, 2019

SergioBertolinSG commented Apr 5, 2016 •

edited by DeepDiver1975

SergioBertolinSG commented Apr 20, 2016 •

edited