ownCloud
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode

Storage

Abstract

This service provides an oCIS extension that wraps reva and adds an opinionated configuration to it.

Architecture Overview

The below diagram shows the oCIS services and the contained reva services within as dashed boxes. In general:

  1. A request comes in at the proxy and is authenticated using OIDC.
  2. It is forwarded to the oCIS frontend which handles ocs and ocdav requests by talking to the reva gateway using the CS3 API.
  3. The gateway acts as a facade to the actual CS3 services: storage providers, user providers, group providers and sharing providers.
proxy
proxy
gateway
gateway
gateway
gateway
authregistry
authregistry
storageregistry
storageregistry
storage users
storage users
storageprovider
storageprovider
dataprovider
dataprovider
storage home
storage home
storageprovider
storageprovider
dataprovider
dataprovider
storage public link
storage public link
publicstorageprovider
publicstorageprovider
authprovider
publicshares
authprovider...
storage metadata
storage metadata
storageprovider
storageprovider
dataprovider
dataprovider
sharing
sharing
usershareprovider
usershareprovider
publicshareprovider
publicshareprovider
users
users
userprovider
userprovider
groups
groups
groupprovider
groupprovider
authbasic
authbasic
authprovider
authprovider
authbearer
authbearer
authprovider
authprovider
accounts
accounts
frontend
frontend
datagateway
datagateway
ocdav
ocdav
ocs
ocs
ocis
ocis
reva
reva
deprecated
deprec...
Viewer does not support full SVG 1.1

The dashed lines in the diagram indicate requests that are made to authenticate requests or lookup the storage provider:

  1. After authenticating a request, the proxy may either use the CS3 userprovider or the accounts service to fetch the user information that will be minted into the x-access-token.
  2. The gateway will verify the JWT signature of the x-access-token or try to authenticate the request itself, e.g. using a public link token.
The bottom part is lighter because we will deprecate it in favor of using only the CS3 user and group providers after moving some account functionality into reva and glauth. The metadata storage is not registered in the reva gateway to separate metadata necessary for running the service from data that is being served directly.

Endpoints and references

In order to reason about the request flow, two aspects in the architecture need to be understood well:

  1. What kind of namespaces are presented at the different WebDAV and CS3 endpoints?
  2. What kind of resource references are exposed or required: path or id based?