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: https://github.com/nextcloud/terms_of_service/blob/6d9465b5ae24871a68efb3ae72c4ef8a6e2d6d85/lib/Filesystem/CacheWrapper.php#L44 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.