Fixes#3890
If we do a put request without a body the current code still tries to
read the body. This patch makes sure that we do not try to read the body
if the content length is 0.
See RFC 2616 Section 4.3
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* Moved some interface definitions to Server.php (more to come)
* Build/Query only for existing classes in the AppContainer
* Build/Query only for classes of the App in the AppContainer
* Offload other stuff to the servercontainer
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
CSP nonces are a feature available with CSP v2. Basically instead of saying "JS resources from the same domain are ok to be served" we now say "Ressources from everywhere are allowed as long as they add a `nonce` attribute to the script tag with the right nonce.
At the moment the nonce is basically just a `<?php p(base64_encode($_['requesttoken'])) ?>`, we have to decode the requesttoken since `:` is not an allowed value in the nonce. So if somebody does on their own include JS files (instead of using the `addScript` public API, they now must also include that attribute.)
IE does currently not implement CSP v2, thus there is a whitelist included that delivers the new CSP v2 policy to newer browsers. Check http://caniuse.com/#feat=contentsecuritypolicy2 for the current browser support list. An alternative approach would be to just add `'unsafe-inline'` as well as `'unsafe-inline'` is ignored by CSPv2 when a nonce is set. But this would make this security feature unusable at all in IE. Not worth it at the moment IMO.
Implementing this offers the following advantages:
1. **Security:** As we host resources from the same domain by design we don't have to worry about 'self' anymore being in the whitelist
2. **Performance:** We can move oc.js again to inline JS. This makes the loading way quicker as we don't have to load on every load of a new web page a blocking dynamically non-cached JavaScript file.
If you want to toy with CSP see also https://csp-evaluator.withgoogle.com/
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
This cleans up a bit the OCSController/Middleware. Since the 2 versions
of OCS differ a bit. Moved a lot of stuff internal since it is of no
concern to the outside.
Having two code paths for this is unreliable and can lead to bugs. Also, in some cases Apache isn't setting the PATH_INFO variable when mod_rewrite is used.
Fixes https://github.com/nextcloud/server/issues/983
The OCS Controller requires a DataResponse object to be returned.
This means that all error handling will have to be done via exceptions
thrown and handling in the middleware.
OVH has implemented load balancing in a very questionable way where the reverse proxy actually internally adds some cookies which would trigger a security exception. To work around this, this change only checks for the session cookie.
'core' and 'settings' are just apps but we treat them slightly
different. Make sure that we construct the correct namespace so we can
actually do automatic AppFramework stuff.
One of the possibilities of the old OCS API is that you can define the
url yourself.
This PR makes this possible again by adding an optional root elemenet to
the route. Routes are thus:
.../ocs/v2.php/<root>/<url>
By default <root> = apps/<app>
This will allow for example the provisioning API etc to be in
../ovs/v2/php/cloud/users
Class Throttler implements the bruteforce protection for security actions in
Nextcloud.
It is working by logging invalid login attempts to the database and slowing
down all login attempts from the same subnet. The max delay is 30 seconds and
the starting delay are 200 milliseconds. (after the first failed login)
* Move a-b to PSR-4
* Move c-d to PSR-4
* Move e+g to PSR-4
* Move h-l to PSR-4
* Move m-r to PSR-4
* Move s-u to PSR-4
* Move files/ to PSR-4
* Move remaining tests to PSR-4
* Remove Test\ from old autoloader
