Easily Load Web Extensions

[tbsbdr]

Description

User Stories

• As an Sysadmin I want to add a web extension very easily so that I can enrich the functionality of the Web UI without much manual configuration.

Value

• increase adoption of web apps and extensions

Acceptance Criteria

• web service allows to load web apps from a dedicated, configurable apps folder
• contents of the apps folder are a) app releases (.tar files) and b) optionally config snippets for the individual apps
• web service extracts app releases at runtime and:
  • makes the contents available via http GET
  • inserts the apps into the config.json
• mechanism to disable apps for the next service restart (e.g. with a file name prefix/suffix)
• app signing for integrity check (followup?)

Context / history

• first idea from @dragotin and Benedikt https://zoom.us/wb/doc/GG5IHxuaS2OEnn3UMXkIGg/p/54350342586368
  

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 ocis charts is compatible

[micbar]

I would go for a "web" service based approach in the first iteration.

• Add an extra config for an WEB_EXTENSIONS_PATH
  • add an extra route to the proxy as a web extensions-web prefix
  • add a mechanism to parse yaml files in the extensions to collect snippets for the merged config.json
  • add a signatures.json to every web extension (like oc10) and validate in the ocis web service

[fschade]

@micbar, @kulmann, @tbsbdr

web service allows to load web apps from a dedicated, configurable apps folder is fine in my opinion but i have concerns regarding contents of the apps folder are a) app releases (.tar files) in combination with web service extracts app releases at runtime and:... could be a tar.BOMB 💣 💥

following suggestions:

• ocis scans a folder at startup to obtain available web-apps (apps have to follow a strict format)
• the whatever-app.tar.gz is not extracted automatically at runtime (or startup) , instead we add a cli admin command to load an app, which means:
  • the cli loads the app (filesystem, gitHub release, etc.)
  • the cli scans the app if the artifact's contain everything and are valid (integrity, structure, configuration)
  • the cli extracts the app to the destination folder which is exposed to the public and can be loaded by web

another topic regarding app configuration, if a app can change over time (new version, etc.) the contained config should not be changed (user edit), instead i recommend the following:

• the app-name/config.json should not be edited and stays the same over time.
• the user has to add the app config to OCIS_HOME/config/web.yaml
• ocis merges OCIS_HOME/config/web.yaml and app-name/config.json together, YAML key values win.

[kulmann]

I don't want to build a CLI in the first iteration. That's a UX improvement for small instance admins later on. Let's let the user unpack the app artifact (tarball) themselves.

[fschade]

@kulmann, @dragotin, @micbar, @tbsbdr ready for testing, please have a look and tell me if something is missing