This changeset removes the static class `OC_Request` and moves the functions either into `IRequest` which is accessible via `\OC::$server::->getRequest()` or into a separated `TrustedDomainHelper` class for some helper methods which should not be publicly exposed.
This changes only internal methods and nothing on the public API. Some public functions in `util.php` have been deprecated though in favour of the new non-static functions.
Unfortunately some part of this code uses things like `__DIR__` and thus is not completely unit-testable. Where tests where possible they ahve been added though.
Fixes https://github.com/owncloud/core/issues/13976 which was requested in https://github.com/owncloud/core/pull/13973#issuecomment-73492969
\Sabre\DAV\Auth\Backend\AbstractBasic::authenticate was only calling \OC_Connector_Sabre_Auth::validateUserPass when the response of \Sabre\HTTP\BasicAuth::getUserPass was not null.
However, there is a case where the value can be null and the user could be authenticated anyways: The authentication via ownCloud web-interface and then accessing WebDAV resources. This was not possible anymore with this patch because it never reached the code path in this scenario.
This patchs allows authenticating with a session without isDavAuthenticated value stored (this is for ugly WebDAV clients that send the cookie in any case) and thus the functionality should work again.
To test this go to the admin settings and test if the WebDAV check works fine. Furthermore all the usual stuff (WebDAV / Shibboleth / etc...) needs testing as well.
There are a lot of clients that support multiple WebDAV accounts in the same application. However, they resent all the cookies they received from one of the accounts also to the other one. In the case of ownCloud this means that we will always show the user from the session and not the user that is specified in the basic authentication header.
This patch adds a workaround the following way:
1. If the user authenticates via the Sabre Auth Connector add a hint to the session that this was authorized via Basic Auth (this is to prevent logout CSRF)
2. If the request contains this hint and the username specified in the basic auth header differs from the one in the session relogin the user using basic auth
Fixes https://github.com/owncloud/core/issues/11400 and https://github.com/owncloud/core/issues/13245 and probably some other issues as well.
This requires proper testing also considering LDAP / Shibboleth and whatever instances.
When uploading files to an OC ext storage backend or when using server
to server sharing storage, part files aren't needed because the backend
already has its own part files and takes care of the final atomic rename
operation.
This also fixes issues when using two encrypted ownCloud instances where
one mounts the other either as external storage (ownCloud backend) or
through server to server sharing.
I was getting a lot of these in my logs for no apparent reason, and file
uploads were failing:
{"app":"webdav","message":"Sabre\\DAV\\Exception\\ServiceUnavailable: ","level":4,"time":"2015-01-06T15:33:39+00:00"}
In order to debug it, I had to add unique messages to all the places where
this exception was thrown, to identify which one it was, and that made the
logs much more useful:
{"app":"webdav","message":"Sabre\\DAV\\Exception\\ServiceUnavailable: Encryption is disabled","level":4,"time":"2015-01-06T15:36:47+00:00"}
Added oc:tags and oc:favorites in PROPFIND response.
It is possible to update them with PROPPATCH.
These properties are optional which means they need to be requested
explicitly
Convert \OCP\Files\StorageNotAvailableException to
\Sabre\DAV\Exception\ServiceUnavailable for every file/directory
operation happening inside of SabreDAV.
This is necessary to avoid having the exception bubble up to remote.php
which would return an exception page instead of an appropriate response.
When doing a PROPFIND on the root and one of the mount points is not
available, the returned quota attributes will now be zero.
This fix prevents the expected exception to make the whole call fail.
Assume a permission issue whenever a file could not be deleted.
This is because some storages are not able to return permissions, so a
permission denied situation can only be triggered during direct
deletion.
If client does not send content length header on webdav upload (e.g. because the content comes from a stream and its length is not predictable) the put() method should not try to compare the content length value with the actually amount of received data, because this will always fail and results in a BadRequest exception. So the check will only be performed if $_SERVER['CONTENT_LENGTH'] is set.
Thomas Müller
Jenkins for ownCloud
Lukas Reschke
Morris Jobke
Christian Seiler
Robin Appelman
Vincent Petry
Chris Wilson
derkostka
Joas Schilling
Bjoern Schiessle
libasys
scolebrook
chli1
Clark Tomlinson