Let web apps register CSP rules

[kulmann]

Description

The current implementation of registering CSP rules is not flexible enough and frequently breaks OpenCloud instances (at least the web ui). Since CSP rules are for the web client it would be good if we'd have a kind of "base CSP rule set" and then let web apps register additional CSP rules, merging them all together. I'll give examples below.

User Stories

• As a web app developer I want my app with external sources to work out of the box so that the installation experience is as simple as possible for the OpenCloud admin.

Value

Easy setup, less failures in the web ui when installing a web app.

Status quo / context / examples

Web apps currently come with a manifest.json which defines the entrypoint .js file and can set default config for an app. Optionally we allow the admin to place a config.json file in the same folder as the manifest.json to define instance specific config for the app which survives an app update. This is already great! Sometimes CSP rules need to be added so that the web app works as desired. See examples below. All of that should also work in the apps.yaml (like the config already does).

Example:

• We have an external-sites app for adding external sites to the app switcher. You can decide to add those embedded into an iframe, which makes really nice integration of websites possible with quite good UX for the users. If you decide to add wikipedia.com as embedded external site you need to add some CSP rules for wikipedia.net and wikipedia.com to your csp.yaml file. This breaks the previously described great admin experience. It would be a nice admin experience if you could add the additional csp rules to the manifest.json (app defaults) and config.json (admin config) where you define the app switcher entry.

Concerns

• Security: Trusting a web app to only register harmless CSP rules is short sighted. We'd need to make it very very clear to the admin which CSP rules are being added if an admin decides to install a web app.

Acceptance Criteria

• the backend is able to merge multiple CSP rule sources into one set of CSP rules.
• the console service is able to add CSP rules at runtime.

Definition of ready

• [ ] Everybody needs to understand the value written in the user story
• [ ] Acceptance criteria have to be defined
• [ ] All dependencies of the user story need to be identified
• [ ] Feature should be seen from an end user perspective
• [ ] Story has to be estimated
• [ ] Story points need to be less than 20

Definition of done

• Functional requirements
  • [ ] Functionality described in the user story works
  • [ ] Acceptance criteria are fulfilled
• Quality
  • [ ] Code review happened
  • [ ] CI is green (that includes new and existing automated tests)
  • [ ] Critical code received unit tests by the developer
• Non-functional requirements
  • [ ] No sonar cloud issues
• Configuration changes
  • [ ] The next branch of the OpenCloud charts is compatible

Notes

I originally posted this in https://github.com/owncloud/ocis/issues/9863 - there was some discussion going on.

[dschmidt]

imho apps should provide a default, but it should also be possible to remove/not use defaults. E.g. the maps app needs tile.openstreetmap.org in image-src, but it's possible to use other tile sources and then one doesnt want the default domain in the csp

[dragonchaser]

I do not like the acceptance criteria: CSP rules registered by web-apps should be stored in nats-kv with a TTL and be removed if the web-app is disabled/stops/etc. The csp rules should be rendered from those settings + the presets/custom configs from #1475 otherwise we will probably end up with a mess of csp rules and we would have to restart OC to clean them up.