Clients do not get useful message if ToS not accepted

[tobiasKaminsky]

• set up ToS
• try to sync with any client
• see "access forbidden"
  --> user should have better description

[tobiasKaminsky]

to reproduce:

• reset ToS
• ./occ config:app:set terms_of_service tos_on_public_shares --value '1'
• (this should not be needed!)
• see sometimes 403 or 404

[nickvergessen]

So this needs some extending on the server so apps can even specify a reason. The biggest issue is this happens after a isCreatable call etc, so the storage wrapper returns a boolean and doesn't have an option for a reason or something.

[julien-nc]

To make this a bit more difficult, the cache is sometimes used. If ToS are not signed, the CacheWrapper just changes the Node permissions:

terms_of_service/lib/Filesystem/CacheWrapper.php

Line 44 in 6d9465b

$entry['permissions'] &= $this->mask;

In this case, it seems hard to pass detailed information.

I tried throwing a OCA\DAV\Connector\Sabre\Exception\Forbidden in CacheWrapper and StorageWrapper with an "informative" message. This is goes up to Sabre and the DAV response contains the message. @nickvergessen Is it a satisfying solution?

Only differences I could see with before:

• listing user's root directory is not possible anymore
• listing a subdirectory in files app with ToS not being signed leads to an infinite retry loop even if DAV response contains <o:retry xmlns:o="o:">false</o:retry>. Is the Files app supposed to avoid retrying according to DAV response retry value?

[nickvergessen]

Well the functions are not supposed to throw. I guess it will break a lot of apps and other things when a "isCreatable" function call all of a sudden throws a Sabre exception.