For group shares we can have children. Those are custom shares when a
user has moved or deleted a group share. Those also have to be deleted
if the group share is removed.
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'
```
ownCloud might not yet be setup. This causes an issue as the user config requires a setup ownCloud. Thus this needs a block whether ownCloud is installed or not.
Fixes https://github.com/owncloud/core/issues/21955
If a user deletes a group share we create a special share entry. To the
API this is just a normal group share for that user with permissions 0.
But we should not return this.
This adds a new CSRF manager for unit testing purposes, it's interface is based upon https://github.com/symfony/security-csrf. Due to some of our required custom changes it is however not possible to use the Symfony component directly.
This allows recipient to delete a share. For user shares this is the
same as deleting (at least for now).
But for group shares this means creating a new share with type 2. With
permissions set to 0.
After the initial installation ownCloud will write some content into the .htaccess file such as the 404 or 403 directives. This adds a magic marker into the .htaccess file and only the content above this marker will be compared in the integrity checker.
This change requires the usage of a path instead of the App ID when signing code. This has the advantage that developers can also sign code under a different location to make it easier. (e.g. remove `.git`, …)
Also it adds an example command usage as well as a link to the documentation
Added config.php option to replace the default implementation of system
tag manager and system tag object mapper.
Also adjusted the comments manager factory to inject the server container
CredentialsManager performs a simple role, of storing and retrieving
encrypted credentials from the database. Credentials are stored by user
ID (which may be null) and credentials identifier. Credentials
themselves may be of any type that can be JSON encoded.
The rationale behind this is to avoid further (mis)use of
oc_preferences, which was being used for all manner of data not related
to user preferences.
Now that we support multiple managers we communicate shares to the
outside as 'providerId:shareId'. This makes sures that id's are unique
when references from the OCS API.
However, since we do not want to break the OCS API v1 we need to
somewhat hack around this.
When we switch to OCS API v2 (which we should when we support more
custom providers). We will change the id to always be the fullShareId.
This adds a hidden config flag that allows somebody to disable the code integrity check. If `integrity.check.disabled` is set to `true` in the config file:
1. The integrity check functions will return always an empty result
2. The integrity check is not performed when installing apps
3. The integrity check is not performed when updating apps
4. The integrity check is not performed when updating the core
Furthermore this adds support for a list of channels that the code checker will run on. At the moment this is only stable because I didn't want to break any build scripts that we have. Once we have a proper CA setup and updated the build process to sign the releases we can add the RC, alpha, beta as well as daily releases. So everything except "git" basically.