Allows to inject something into the default content policy. This is for
example useful when you're injecting Javascript code into a view belonging
to another controller and cannot modify its Content-Security-Policy itself.
Note that the adjustment is only applied to applications that use AppFramework
controllers.
To use this from your `app.php` use `\OC::$server->getContentSecurityPolicyManager()->addDefaultPolicy($policy)`,
$policy has to be of type `\OCP\AppFramework\Http\ContentSecurityPolicy`.
To test this add something like the following into an `app.php` of any enabled app:
```
$manager = \OC::$server->getContentSecurityPolicyManager();
$policy = new \OCP\AppFramework\Http\ContentSecurityPolicy(false);
$policy->addAllowedFrameDomain('asdf');
$policy->addAllowedScriptDomain('yolo.com');
$policy->allowInlineScript(false);
$manager->addDefaultPolicy($policy);
$policy = new \OCP\AppFramework\Http\ContentSecurityPolicy(false);
$policy->addAllowedFontDomain('yolo.com');
$manager->addDefaultPolicy($policy);
$policy = new \OCP\AppFramework\Http\ContentSecurityPolicy(false);
$policy->addAllowedFrameDomain('banana.com');
$manager->addDefaultPolicy($policy);
```
If you now open the files app the policy should be:
```
Content-Security-Policy:default-src 'none';script-src yolo.com 'self' 'unsafe-eval';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src yolo.com 'self';connect-src 'self';media-src 'self';frame-src asdf banana.com 'self'
```
Otherwise an empty string is used indicating the cookie is only valid for those resources. This can lead to eunexpected behaviour.
Fixes https://github.com/owncloud/core/issues/19196
While not encoding the HTML tags in the JSON response is perfectly fine since we set the proper mimetype as well as disable content sniffing a lot of automated code scanner do report this as security bug. Encoding them leads to less discussions and a lot of saved time.
`json_encode` fails hard on PHP >= 5.5 if a non UTF-8 value is specified by returning false. Older PHP versions just nullify the value which makes it at least somewhat usable.
This leads to very confusing errors which are very hard to debug since developers are usually not aware of this. In this case I'd consider throwing a fatal exception – since it arguably is an error situation – is a fair solution since this makes developers and administrators aware of any occurence of the problem so that these bugs can get fixed.
Fixes https://github.com/owncloud/core/issues/17265
For enhanced security it is important that there is also a way to disallow domains, including the default ones.
With this commit every method gets added a new "disallow" function.
* enhance the app development experience - you can look up the
method introduction right inside the code without searching
via git blame
* easier to write apps for multiple versions
Despite it's PHPDoc the function might return `null` which was not properly catched and thus in some situations the share was resolved to the sharing users root directory.
To test this perform the following steps:
* Share file in owncloud 7 (7.0.4.2)
* Delete the parent folder of the shared file
* The share stays is in the DB and the share via the sharelink is inaccessible. (which is good)
* Upgrade to owncloud 8 (8.0.2) (This step is crucial. The bug is not reproduceable without upgrading from 7 to 8. It seems like the old tokens are handled different than the newer ones)
* Optional Step: Logout, Reset Browser Session, etc.
* Access the share via the old share url: almost empty page, but there is a dowload button which adds a "/download" to the URL.
* Upon clicking, a download.zip is downloaded which contains EVERYTHING from the owncloud directory (of the user who shared the file)
* No exception is thrown and no error is logged.
This will add a check whether the share is a valid one and also adds unit tests to prevent further regressions in the future. Needs to be backported to ownCloud 8.
Adding a proper clean-up of the orphaned shares is out-of-scope and would probably require some kind of FK or so.
Fixes https://github.com/owncloud/core/issues/15097
* Original avatarcontroller migrated to the appframework
* Added DataDisplayResponse that show data inline in the browser (used
to retrun the image)
* Removed some unneeded code
* Added unit tests for the avatarcontroller
This is required when working with stuff such as PDF.js in the files_pdfviewer application. Opt-in only.
Master change only because the stable CSP policies has a failback that allows nearly anything 🙈
First stab at the StreamResponse, see #12988
The idea is to use an interface ICallbackResponse (I'm not 100% happy with the name yet, suggestions?) that allow the response to output things in its own way, for instance stream the file using readfile
Unittests are atm lacking, plan is to
check if a mock of ICallbackResponse will be used by calling its callback (also unhappy with this name) method
Usage is:
$response = new StreamResponse('path/to/file');
rename io to output, add additional methods and handle error and not modified cases when using StreamResponse
fix indention and uppercasing, also handle forbidden cases
fix indention
fix indention
no forbidden, figuring out if a file is really readable is too complicated to get to work across OSes and streams
remove useless import
remove useless import
fix intendation
This change allows AppFramework applications to specify a custom CSP header for example when the default policy is too strict. Furthermore this allows us to partially migrate away from CSS and allowed eval() in our JavaScript components.
Legacy ownCloud components will still use the previous policy. Application developers can use this as following in their controllers:
```php
$response = new TemplateResponse('activity', 'list', []);
$cspHelper = new ContentSecurityPolicyHelper();
$cspHelper->addAllowedScriptDomain('www.owncloud.org');
$response->addHeader('Content-Security-Policy', $cspHelper->getPolicy());
return $response;
```
Fixes https://github.com/owncloud/core/issues/11857 which is a pre-requisite for https://github.com/owncloud/core/issues/13458 and https://github.com/owncloud/core/issues/11925
add logSettingsController
add download logfile button
move getEntries to LogSettingsController
move set log level to logsettingscontroller.php
add warning if logfile is bigger than 100MB
add unit test for set log level
fix typecasting, add new line at EoF
show log and logfile download only if log_type is set to owncloud
add unit test for getFilenameForDownload
Currently there is no AppFramework way to modify cookies, which makes it unusable for quite some use-cases or results in untestable code.
This PR adds some basic functionalities to add and invalidate cookies.
Usage:
```php
$response = new TemplateResponse(...);
$response->addCookie('foo', 'bar');
$response->invalidateCookie('foo');
$response->addCookie('bar', 'foo', new \DateTime('2015-01-01 00:00'));
```
Existing cookies can be accessed with the AppFramework using `$this->request->getCookie($name)`.
fix docstrings
adjust copyright date
another copyright date update
another header update
implement third headers argument, fix indention, fix docstrings
fix docstrings
remove methodannotationreader namespace
fix namespace for server container
fix tests
fail if with cors credentials header is set to true, implement a reusable preflighted cors method in the controller baseclass, make corsmiddleware private and register it for every request
remove uneeded local in cors middleware registratio
dont uppercase cors to easily use it from routes
fix indention
comment fixes
explicitely set allow credentials header to false
dont depend on better controllers PR, fix that stuff later
split cors methods to be in a seperate controller for exposing apis
remove protected definitions from apicontroller since controller has it
