mirror of
https://github.com/opencloud-eu/opencloud.git
synced 2026-01-04 11:19:39 -06:00
cleanup: Remove unneeded _index.md files from docs
This commit removes the `doc/service/<name>/_index.md` files for service that provide a README.md in their own directory. The CI's docs pipeline generates and publishes (to the `docs` branch) the _index.md files from the READMEs. We don't need to have these files duplicated `master` branch of the git repo. They just cause confusion and are not kept in sync with the READMEs on the `master` branch.
This commit is contained in:
Ralf Haferkamp
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: Antivirus
|
||||
date: 2023-03-16:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/antivirus
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
|
||||
## Antivirus Service
|
||||
|
||||
The `antivirus` service is responsible for scanning files for viruses.
|
||||
|
||||
### Configuration
|
||||
|
||||
#### Antivirus Scanner Type
|
||||
|
||||
The antivirus service currently supports [ICAP](https://tools.ietf.org/html/rfc3507) and [ClamAV](http://www.clamav.net/index.html) as antivirus scanners. The `ANTIVIRUS_SCANNER_TYPE` environment variable is used to select the scanner. The detailed configuration for each scanner heavily depends on the scanner type selected. See the environment variables for more details.
|
||||
|
||||
- For `icap`, only scanners using the `X-Infection-Found` header are currently supported.
|
||||
- For `clamav` only local sockets can currently be configured.
|
||||
|
||||
#### Maximum Scan size
|
||||
|
||||
Several factors can make it necessary to limit the maximum filesize the antivirus service will use for scanning. Use the `ANTIVIRUS_MAX_SCAN_SIZE` environment variable to scan only a given amount of bytes. Obviously, it is recommended to scan the whole file, but several factors like scanner type and version, bandwidth, performance issues, etc. might make a limit necessary.
|
||||
|
||||
#### Infected File Handling
|
||||
|
||||
The antivirus service allows three different ways of handling infected files. Those can be set via the `ANTIVIRUS_INFECTED_FILE_HANDLING` environment variable:
|
||||
|
||||
- `delete`: (default): Infected files will be deleted immediately, further postprocessing is cancelled.
|
||||
- `abort`: (advanced option): Infected files will be kept, further postprocessing is cancelled. Files can be manually retrieved and inspected by an admin. To identify the file for further investigation, the antivirus service logs the abort/infected state including the file ID. The file is located in the `storage/users/uploads` folder of the ocis data directory and persists until it is manually deleted by the admin via the [Manage Unfinished Uploads](https://doc.owncloud.com/ocis/next/deployment/services/s-list/storage-users.html#manage-unfinished-uploads) command.
|
||||
- `continue`: (obviously not recommended): Infected files will be marked via metadata as infected but postprocessing continues normally. Note: Infected Files are moved to their final destination and therefore not prevented from download which includes the risk of spreading viruses.
|
||||
|
||||
In all cases, a log entry is added declaring the infection and handling method and a notification via the `userlog` service sent.
|
||||
|
||||
#### Scanner Inaccessibility
|
||||
|
||||
In case a scanner is not accessible by the antivirus service like a network outage, service outage or hardware outage, the antivirus service uses the `abort` case for further processing, independent of the actual setting made. In any case, an error is logged noting the inaccessibility of the scanner used.
|
||||
|
||||
### Operation Modes
|
||||
|
||||
The antivirus service can scan files during `postprocessing`. `on demand` scanning is currently not available and might be added in a future release.
|
||||
|
||||
#### Postprocessing
|
||||
|
||||
The antivirus service will scan files during postprocessing. It listens for a postprocessing step called `virusscan`. This step can be added in the environment variable `POSTPROCESSING_STEPS`. Read the documentation of the [postprocessing service](https://github.com/owncloud/ocis/tree/master/services/postprocessing) for more details.
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Audit
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/audit
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Auth-Basic
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/auth-basic
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Auth-Bearer
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/auth-bearer
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: Eventhistory
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/eventhistory
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The `eventhistory` consumes all events from the configured event system like NATS, stores them and allows other services to retrieve them via an eventid.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Running the eventhistory service without an event system like NATS is not possible.
|
||||
|
||||
## Consuming
|
||||
|
||||
The `eventhistory` services consumes all events from the configured event system.
|
||||
|
||||
## Storing
|
||||
|
||||
The `eventhistory` service stores each consumed event via the configured store in `EVENTHISTORY_STORE_TYPE`. Possible stores are:
|
||||
- `mem`: Basic in-memory store and the default.
|
||||
- `ocmem`: Advanced in-memory store allowing max size.
|
||||
- `redis`: Stores data in a configured redis cluster.
|
||||
- `etcd`: Stores data in a configured etcd cluster.
|
||||
- `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
|
||||
- `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
|
||||
|
||||
1. Note that in-memory stores are by nature not reboot persistent.
|
||||
2. Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
|
||||
3. Events stay in the store for 2 weeks by default. Use `EVENTHISTORY_RECORD_EXPIRY` to adjust this value.
|
||||
4. The eventhistory service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
|
||||
|
||||
## Retrieving
|
||||
|
||||
Other services can call the `eventhistory` service via a grpc call to retrieve events. The request must contain the eventid that should be retrieved.
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
title: Frontend
|
||||
date: 2023-05-03T16:23:46.388689927+02:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/services/frontend
|
||||
geekdocFilePath: README.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
<!-- Do not edit this file, it is autogenerated. Edit the service README.md instead -->
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
The frontend service translates various owncloud related HTTP APIs to CS3 requests.
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
* [Endpoints Overview](#endpoints-overview)
|
||||
* [appprovider](#appprovider)
|
||||
* [archiver](#archiver)
|
||||
* [datagateway](#datagateway)
|
||||
* [ocs](#ocs)
|
||||
* [Sharing](#sharing)
|
||||
* [Scalability](#scalability)
|
||||
* [Define Read-Only Attributes](#define-read-only-attributes)
|
||||
* [Caching](#caching)
|
||||
* [Example Yaml Config](#example-yaml-config)
|
||||
|
||||
## Endpoints Overview
|
||||
|
||||
Currently, the frontend service handles requests for three functionalities, which are `appprovider`, `archiver`, `datagateway` and `ocs`.
|
||||
|
||||
### appprovider
|
||||
|
||||
The appprovider endpoint, by default `/app`, forwards HTTP requests to the CS3 [App Registry API](https://cs3org.github.io/cs3apis/#cs3.app.registry.v1beta1.RegistryAPI)
|
||||
|
||||
### archiver
|
||||
|
||||
The archiver endpoint, by default `/archiver`, implements zip and tar download for collections of files. It will internally use the CS3 API to initiate downloads and then stream the individual files as part of a compressed file.
|
||||
|
||||
### datagateway
|
||||
|
||||
The datagateway endpoint, by default `/data`, forwards file up- and download requests to the correct CS3 data provider. OCIS starts a dataprovider as part of the storage-* services. The routing happens based on the JWT that was created by a storage provider in response to an `InitiateFileDownload` or `InitiateFileUpload` request.
|
||||
|
||||
### ocs
|
||||
|
||||
The ocs endpoint, by default `/ocs`, implements the ownCloud 10 Open Collaboration Services API by translating it into CS3 API requests. It can handle users, groups, capabilities and also implements the files sharing functionality on top of CS3. The `/ocs/v[12].php/cloud/user/signing-key` is currently handled by the dedicated [ocs](https://github.com/owncloud/ocis/tree/master/services/ocs) service.
|
||||
|
||||
### Sharing
|
||||
|
||||
Aggregating share information is one of the most time consuming operations in OCIS. The service fetches a list of either received or created shares and has to stat every resource individually. While stats are fast, the default behavior scales linearly with the number of shares.
|
||||
|
||||
To save network trips the sharing implementation can cache the stat requests with an in memory cache or in Redis. It will shorten the response time by the network round-trip overhead at the cost of the API only eventually being updated.
|
||||
|
||||
Setting `FRONTEND_OCS_RESOURCE_INFO_CACHE_TTL=60` would cache the stat info for 60 seconds. Increasing this value makes sense for large deployments with thousands of active users that keep the cache up to date. Low frequency usage scenarios should not expect a noticeable improvement.
|
||||
|
||||
## Scalability
|
||||
|
||||
While the frontend service does not persist any data, it does cache information about files and filesystem (`Stat()`) responses and user information. Therefore, multiple instances of this service can be spawned in a bigger deployment like when using container orchestration with Kubernetes, when configuring `FRONTEND_OCS_RESOURCE_INFO_CACHE_STORE` and the related config options.
|
||||
|
||||
## Define Read-Only Attributes
|
||||
|
||||
A lot of user management is made via the standardized libregraph API. Depending on how the system is configured, there might be some user attributes that an ocis instance admin can't change because of properties coming from an external LDAP server, or similar. This can be the case when the ocis admin is not the LDAP admin. To ease life for admins, there are hints as capabilites telling the frontend which attributes are read-only to enable a different optical representation like being grayed out. To configure these hints, use the environment variable `FRONTEND_READONLY_USER_ATTRIBUTES`, which takes a comma separated list of attributes, see the envvar for supported values.
|
||||
|
||||
You can find more details regarding available attributes at the [libre-graph-api openapi-spec](https://github.com/owncloud/libre-graph-api/blob/main/api/openapi-spec/v1.0.yaml) and on [owncloud.dev](https://owncloud.dev/libre-graph-api/).
|
||||
|
||||
## Caching
|
||||
|
||||
The `frontend` service can use a configured store via `FRONTEND_OCS_RESOURCE_INFO_CACHE_STORE`. Possible stores are:
|
||||
- `memory`: Basic in-memory store and the default.
|
||||
- `ocmem`: Advanced in-memory store allowing max size.
|
||||
- `redis`: Stores data in a configured Redis cluster.
|
||||
- `redis-sentinel`: Stores data in a configured Redis Sentinel cluster.
|
||||
- `etcd`: Stores data in a configured etcd cluster.
|
||||
- `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
|
||||
- `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
|
||||
|
||||
1. Note that in-memory stores are by nature not reboot-persistent.
|
||||
2. Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
|
||||
3. The frontend service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
|
||||
4. When using `redis-sentinel`, the Redis master to use is configured via `FRONTEND_OCS_RESOURCE_INFO_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.
|
||||
## Example Yaml Config
|
||||
{{< include file="services/_includes/frontend-config-example.yaml" language="yaml" >}}
|
||||
|
||||
{{< include file="services/_includes/frontend_configvars.md" >}}
|
||||
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Gateway
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/gateway
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: "Graph"
|
||||
date: 2018-05-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/graph
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This service provides a simple graph world API which can be used by clients or other extensions.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: IDM
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/idm
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The IDM service provides a minimal LDAP Service (based on https://github.com/libregraph/idm) for oCIS. It is started as part of
|
||||
the default configuration and serves as a central place for storing user and group information.
|
||||
|
||||
It is mainly targeted at small oCIS installations. For larger setups it is recommended to replace IDM with a "real" LDAP server
|
||||
or to switch to an external Identity Management Solution.
|
||||
|
||||
IDM listens on port 9325 by default. In the default configuration it only accepts TLS protected connections (LDAPS). The BaseDN
|
||||
of the LDAP tree is `o=libregraph-idm`. IDM gives LDAP write permissions to a single user
|
||||
(DN: `uid=libregraph,ou=sysusers,o=libregraph-idm`). Any other authenticated user has read-only access. IDM stores its data in a
|
||||
[boltdb](https://github.com/etcd-io/bbolt) file `idm/ocis.boltdb` inside the oCIS base data directory.
|
||||
|
||||
Note: IDM is limited in its functionality. It only supports a subset of the LDAP operations (namely BIND, SEARCH, ADD, MODIFY, DELETE).
|
||||
Also IDM currently does not do any schema verification (e.g. structural vs. auxiliary object classes, require and option attributes,
|
||||
syntax checks, ...). So it's not meant as a general purpose LDAP server.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: IDP
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/idp
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This service provides an OpenID Connect provider which is the default way to authenticate in oCIS.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: IDP
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/invitations
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This service provides an invitations service to invite guests into the organization.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: NATS
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/nats
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: Notifications
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/notifications
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The notifications extension is responsible for making users aware of changes. It listens on the event bus, filters relevant events, looks up the recipients email address and then queues an email with an external MTA.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: "Ocs"
|
||||
date: 2018-05-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/ocs
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This service provides the OCS API which is required by some ownCloud clients.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,136 +0,0 @@
|
||||
---
|
||||
title: Policies
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/policies
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The policies service provides a new grpc api which can be used to return whether a requested operation is allowed or not. To do so, Open Policy Agent (OPA) is used to determine the set of rules of what is permitted and what is not.
|
||||
|
||||
Policies are written in the [rego query language](https://www.openpolicyagent.org/docs/latest/policy-language/). The location of the rego files can be configured via yaml, a configuration via environment variables is not possible.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
|
||||
## General Information
|
||||
|
||||
The policies service consists of the following modules:
|
||||
|
||||
* Proxy authorization (middleware)
|
||||
* Event authorization (async post-processing)
|
||||
* gRPC API (can be used by other services)
|
||||
|
||||
To configure the policies service, three environment variables need to be defined:
|
||||
|
||||
* `POLICIES_ENGINE_TIMEOUT`
|
||||
* `POLICIES_POSTPROCESSING_QUERY`
|
||||
* `PROXY_POLICIES_QUERY`
|
||||
|
||||
Note that each query setting defines the [Complete Rules](https://www.openpolicyagent.org/docs/latest/#complete-rules) variable defined in the rego rule set the corresponding step uses for the evaluation. If the variable is mistyped or not found, the evaluation defaults to deny. Individual query definitions can be defined for each module.
|
||||
|
||||
To activate a the policies service for a module, it must be started with a yaml configuration that points to one or more rego files. Note that if the service is scaled horizontally, each instance should have access to the same rego files to avoid unpredictable results. If a file path has been configured but the file it is not present or accessible, the evaluation defaults to deny.
|
||||
|
||||
When using async post-processing which is done via the postprocessing service, the value `policies` must be added to the `POSTPROCESSING_STEPS` configuration in postprocessing service in the order where the evaluation should take place.
|
||||
|
||||
variable defined in the Rego rule set the corresponding step uses for the evaluation. If the variable is mistyped or not found, the evaluation defaults to deny. Individual query definitions can be defined for each module.
|
||||
|
||||
To activate the policies service for a module, it must be started with a yaml configuration that points to at least one Rego file that contains the complete rule variable to be queried. Note that if the service is scaled horizontally, each instance should have access to the same Rego files to avoid unpredictable results. If a file path has been configured but the file it is not present or accessible, the evaluation defaults to deny.
|
||||
|
||||
When using async post-processing via the postprocessing service, the value `policies` must be added to the `POSTPROCESSING_STEPS` configuration in the order in which the evaluation should take place. Example: First check if a file contains questionable content via policies. If it looks okay, continue to check for viruses.
|
||||
|
||||
For configuration examples, the [Example Policies](#example-policies) from below are used.
|
||||
|
||||
## Modules
|
||||
|
||||
### gRPC API
|
||||
|
||||
The gRPC API can be used by any other internal service. It can also be used for example by third parties to find out if an action is allowed or not. This layer is already used by the proxy middleware. There is no configuration necessary, because the query setting (complete rule variable) must be part of the request.
|
||||
|
||||
### Proxy Middleware
|
||||
|
||||
The proxy service already includes a middleware which uses the internal [gRPC API](#grpc-api) to evaluate the policies. Since the proxy is in heavy use and every HTTP request is processed here, only simple and quick decisions should be evaluated. More complex queries such as file content evaluation are _strongly_ discouraged.
|
||||
|
||||
### Event Service (Postprocessing)
|
||||
|
||||
This layer is event-based and part of the postprocessing service. Since processing at this point is asynchronous, the operations can also take longer and be more expensive, like evaluating the contents of a file.
|
||||
|
||||
## Defining Policies to Evaluate
|
||||
|
||||
Each module can have as many policy files as needed for evaluation. Files can also include other files if necessary. To use policies, they have to be saved to a location that is accessible to the policies service. As a good starting point, take the config directory and use a subdirectory collecting all the `.rego` files, though any other directory can be defined. The config directory is already accessible by all services and usually is included in a xref:maintenance/b-r/backup.adoc[backup] plan.
|
||||
|
||||
If this is done, it's required to configure the policies service to use these files:
|
||||
|
||||
NOTE: It is important that *all* necessary files are added to the list of files the policies service uses.
|
||||
|
||||
```yaml
|
||||
policies:
|
||||
engine:
|
||||
policies:
|
||||
- your_path_to_policies/proxy.rego
|
||||
- your_path_to_policies/postprocessing.rego
|
||||
- your_path_to_policies/util.rego
|
||||
```
|
||||
|
||||
Once the references to policy files are configured correctly, the _QUERY configuration needs to be defined for the proxy middleware and for the events service.
|
||||
|
||||
## Setting the Query Configuration
|
||||
|
||||
To define a value for the query evaluation, the following scheme is necessary:
|
||||
|
||||
`data.<package-name>.<complete-rule-variable-name>`
|
||||
|
||||
* The keyword `data` is mandatory and must be present.
|
||||
* The `package-name` is defined in one .rego file like `package postprocessing`. It is not related to the filename. For more details, see the [packages](https://www.openpolicyagent.org/docs/latest/policy-language/#packages) documentation.
|
||||
* The `complete-rule-variable-name` is the variable providing the result of the evaluation.
|
||||
* Exact one of the defined files, which is responsible for returning the evaluation result, must contain the combination of `<package-name>` and `<complete-rule-variable-name>`.
|
||||
|
||||
### Proxy
|
||||
|
||||
Note that this setting has to be part of the proxy configuration.
|
||||
|
||||
```yaml
|
||||
proxy:
|
||||
policies_middleware:
|
||||
query: data.proxy.granted
|
||||
```
|
||||
|
||||
The same can be achieved by setting the following environment variable:
|
||||
|
||||
```yaml
|
||||
PROXY_POLICIES_QUERY=data.proxy.granted
|
||||
```
|
||||
|
||||
### Postprocessing
|
||||
|
||||
```yaml
|
||||
policies:
|
||||
postprocessing:
|
||||
query: data.postprocessing.granted
|
||||
```
|
||||
|
||||
The same can be achieved by setting the following environment variable:
|
||||
|
||||
```yaml
|
||||
POLICIES_POSTPROCESSING_QUERY=data.postprocessing.granted
|
||||
```
|
||||
|
||||
As soon as that query is configured, the postprocessing service must be informed to use the policies step by setting the environment variable:
|
||||
|
||||
```yaml
|
||||
POSTPROCESSING_STEPS=policies
|
||||
```
|
||||
|
||||
Note that additional steps can be configured and their position in the list defines the order of processing. For details see the postprocessing service documentation.
|
||||
|
||||
## Rego Key Match
|
||||
|
||||
To identify available keys for OPA, you need to look at [engine.go](https://github.com/owncloud/ocis/blob/master/services/policies/pkg/engine/engine.go) and the [policies.swagger.json](https://github.com/owncloud/ocis/blob/master/protogen/gen/ocis/services/policies/v0/policies.swagger.json) file. Note that which keys are available depends on from which module it is used.
|
||||
|
||||
## Example Policies
|
||||
|
||||
The policies service contains a set of preconfigured example policies. See the [deployment examples](https://github.com/owncloud/ocis/tree/master/deployments/examples) directory for details. The contained policies disallow Infinite Scale to create certain file types, both via the proxy middleware and the events service via postprocessing.
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: Postprocessing
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/postprocessing
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The `postprocessing` service handles the coordination of asynchronous postprocessing steps.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
|
||||
## General Prerequisites
|
||||
|
||||
To use the postprocessing service, an event system needs to be configured for all services. By default, `ocis` ships with a preconfigured `nats` service.
|
||||
|
||||
## Postprocessing Functionality
|
||||
|
||||
The storageprovider service (`storage-users`) can be configured to initiate asynchronous postprocessing by setting the `STORAGE_USERS_OCIS_ASYNC_UPLOADS` environment variable to `true`. If this is the case, postprocessing will get initiated *after* uploading a file and all bytes have been received.
|
||||
|
||||
The `postprocessing` service will then coordinate configured postprocessing steps like scanning the file for viruses. During postprocessing, the file will be in a `processing state` where only a limited set of actions are available. Note that this processing state excludes file accessibility by users.
|
||||
|
||||
When all postprocessing steps have completed successfully, the file will be made accessible for users.
|
||||
|
||||
## Additional Prerequisites for the Postprocessing Service
|
||||
|
||||
When postprocessing has been enabled, configuring any postprocessing step will require the requested services to be enabled and pre-configured. For example, to use the `virusscan` step, one needs to have an enabled and configured `antivirus` service.
|
||||
|
||||
## Postprocessing Steps
|
||||
|
||||
The postprocessing service is individually configurable. This is achieved by allowing a list of postprocessing steps that are processed in order of their appearance in the `POSTPROCESSING_STEPS` envvar. This envvar expects a comma separated list of steps that will be executed. Currently known steps to the system are `virusscan` and `delay`. Custom steps can be added but need an existing target for processing.
|
||||
|
||||
### Virus Scanning
|
||||
|
||||
To enable virus scanning as a postprocessing step after uploading a file, the environment variable `POSTPROCESSING_STEPS` needs to contain the word `virusscan` at one location in the list of steps. As a result, each uploaded file gets virus scanned as part of the postprocessing steps. Note that the `antivirus` service is required to be enabled and configured for this to work.
|
||||
|
||||
### Delay
|
||||
|
||||
Though this is for development purposes only and NOT RECOMMENDED on production systems, setting the environment variable `POSTPROCESSING_DELAY` to a duration not equal to zero will add a delay step with the configured amount of time. ocis will continue postprocessing the file after the configured delay. Use the environment variable `POSTPROCESSING_STEPS` and the keyword `delay` if you have multiple postprocessing steps and want to define their order. If `POSTPROCESSING_DELAY` is set but the keyword `delay` is not contained in `POSTPROCESSING_STEPS`, it will be processed as last postprocessing step without being listed there. In this case, a log entry will be written on service startup to notify the admin about that situation. That log entry can be avoided by adding the keyword `delay` to `POSTPROCESSING_STEPS`.
|
||||
|
||||
### Custom Postprocessing Steps
|
||||
By using the envvar `POSTPROCESSING_STEPS`, custom postprocessing steps can be added. Any word can be used as step name but be careful not to conflict with exising keywords like `virusscan` and `delay`. In addition, if a keyword is misspelled or the corresponding service does either not exist or does not follow the necessary event communication, the postprocessing service will wait forever getting the required response to proceed and does not continue any other processing.
|
||||
|
||||
#### Prerequisites
|
||||
For using custom postprocessing steps you need a custom service listening to the configured event system (see `General Prerequisites`)
|
||||
|
||||
#### Workflow
|
||||
When setting a custom postprocessing step (eg. `"customstep"`) the postprocessing service will eventually sent an event during postprocessing. The event will be of type `StartPostprocessingStep` with its field `StepToStart` set to `"customstep"`. When the custom service receives this event it can safely execute its actions, postprocessing service will wait until it has finished its work. The event contains further information (filename, executing user, size, ...) and also required tokens and urls to download the file in case byte inspection is necessary.
|
||||
|
||||
Once the custom service has finished its work, it should sent an event of type `PostprocessingFinished` via the configured events system. This event needs to contain a `FinishedStep` field set to `"customstep"`. It also must contain the outcome of the step, which can be one of "delete" (abort postprocessing, delete the file), "abort" (abort postprocessing, keep the file) and "continue" (continue postprocessing, this is the success case).
|
||||
|
||||
See the [cs3 org](https://github.com/cs3org/reva/blob/edge/pkg/events/postprocessing.go) for up-to-date information of reserved step names and event definitions.
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
title: Proxy
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/proxy
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The proxy service is an API-Gateway for the ownCloud Infinite Scale microservices. Every HTTP request goes through this service. Authentication, logging and other preprocessing of requests also happens here. Mechanisms like request rate limiting or intrusion prevention are **not** included in the proxy service and must be setup in front like with an external reverse proxy.
|
||||
|
||||
The proxy service is the only service communicating to the outside and needs therefore usual protections against DDOS, Slow Loris or other attack vectors. All other services are not exposed to the outside, but also need protective measures when it comes to distributed setups like when using container orchestration over various physical servers.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
|
||||
## Authentication
|
||||
|
||||
The following request authentication schemes are implemented:
|
||||
|
||||
- Basic Auth (Only use in development, **never in production** setups!)
|
||||
- OpenID Connect
|
||||
- Signed URL
|
||||
- Public Share Token
|
||||
|
||||
## Automatic Quota Assignments
|
||||
|
||||
It is possible to automatically assign a specific quota to new users depending on their role.
|
||||
To do this, you need to configure a mapping between roles defined by their ID and the quota in bytes.
|
||||
The assignment can only be done via a `yaml` configuration and not via environment variables.
|
||||
See the following `proxy.yaml` config snippet for a configuration example.
|
||||
|
||||
```yaml
|
||||
role_quotas:
|
||||
<role ID1>: <quota1>
|
||||
<role ID2>: <quota2>
|
||||
```
|
||||
|
||||
## Automatic Role Assignments
|
||||
|
||||
When users login, they do automatically get a role assigned. The automatic role assignment can be
|
||||
configured in different ways. The `PROXY_ROLE_ASSIGNMENT_DRIVER` environment variable (or the `driver`
|
||||
setting in the `role_assignment` section of the configuration file) select which mechanism to use for
|
||||
the automatic role assignment.
|
||||
|
||||
When set to `default`, all users which do not have a role assigned at the time for the first login will
|
||||
get the role 'user' assigned. (This is also the default behavior if `PROXY_ROLE_ASSIGNMENT_DRIVER`
|
||||
is unset.
|
||||
|
||||
When `PROXY_ROLE_ASSIGNMENT_DRIVER` is set to `oidc` the role assignment for a user will happen
|
||||
based on the values of an OpenID Connect Claim of that user. The name of the OpenID Connect Claim to
|
||||
be used for the role assignment can be configured via the `PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM`
|
||||
environment variable. It is also possible to define a mapping of claim values to role names defined
|
||||
in ownCloud Infinite Scale via a `yaml` configuration. See the following `proxy.yaml` snippet for an
|
||||
example.
|
||||
|
||||
```yaml
|
||||
role_assignment:
|
||||
driver: oidc
|
||||
oidc_role_mapper:
|
||||
role_claim: ocisRoles
|
||||
role_mapping:
|
||||
admin: myAdminRole
|
||||
user: myUserRole
|
||||
spaceadmin: mySpaceAdminRole
|
||||
guest: myGuestRole
|
||||
```
|
||||
|
||||
This would assign the role `admin` to users with the value `myAdminRole` in the claim `ocisRoles`.
|
||||
The role `user` to users with the values `myUserRole` in the claims `ocisRoles` and so on.
|
||||
|
||||
Claim values that are not mapped to a specific ownCloud Infinite Scale role will be ignored.
|
||||
|
||||
Note: An ownCloud Infinite Scale user can only have a single role assigned. If the configured
|
||||
`role_mapping` and a user's claim values result in multiple possible roles for a user, an error
|
||||
will be logged and the user will not be able to login.
|
||||
|
||||
The default `role_claim` (or `PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM`) is `roles`. The `role_mapping` is:
|
||||
|
||||
```yaml
|
||||
admin: ocisAdmin
|
||||
user: ocisUser
|
||||
spaceadmin: ocisSpaceAdmin
|
||||
guest: ocisGuest
|
||||
```
|
||||
|
||||
## Recommendations for Production Deployments
|
||||
|
||||
In a production deployment, you want to have basic authentication (`PROXY_ENABLE_BASIC_AUTH`) disabled which is the default state. You also want to setup a firewall to only allow requests to the proxy service or the reverse proxy if you have one. Requests to the other services should be blocked by the firewall.
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Search
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/search
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This service provides search functionality.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Storage-System
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/storage-system
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: Storage-Users
|
||||
date: 2022-03-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/storage-users
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "Thumbnails"
|
||||
date: 2018-05-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/thumbnails
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The thumbnail service generates thumbnails for image files.
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: Userlog
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/userlog
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The `userlog` service is a mediator between the `eventhistory` service and clients who want to be informed about user related events. It provides an API to retrieve those.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Running the `userlog` service without running the `eventhistory` service is not possible.
|
||||
|
||||
## Storing
|
||||
|
||||
The `userlog` service persists information via the configured store in `USERLOG_STORE_TYPE`. Possible stores are:
|
||||
- `mem`: Basic in-memory store and the default.
|
||||
- `ocmem`: Advanced in-memory store allowing max size.
|
||||
- `redis`: Stores data in a configured redis cluster.
|
||||
- `etcd`: Stores data in a configured etcd cluster.
|
||||
- `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store)
|
||||
- `noop`: Stores nothing. Useful for testing. Not recommended in production environments.
|
||||
|
||||
1. Note that in-memory stores are by nature not reboot persistent.
|
||||
2. Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies.
|
||||
3. The userlog service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
|
||||
|
||||
## Configuring
|
||||
|
||||
For the time being, the configuration which user related events are of interest is hardcoded and cannot be changed.
|
||||
|
||||
## Retrieving
|
||||
|
||||
The `userlog` service provides an API to retrieve configured events. For now, this API is mostly following the [oc10 notification GET API](https://doc.owncloud.com/server/next/developer_manual/core/apis/ocs-notification-endpoint-v1.html#get-user-notifications).
|
||||
|
||||
## Deleting
|
||||
|
||||
To delete events for an user, use a `DELETE` request to `ocs/v2.php/apps/notifications/api/v1/notifications` containing the IDs to delete.
|
||||
|
||||
## Translations
|
||||
|
||||
The `userlog` service has embedded translations sourced via transifex to provide a basic set of translated languages. These embedded translations are available for all deployment scenarios. In addition, the service supports custom translations, though it is currently not possible to just add custom translations to embedded ones. If custom translations are configured, the embedded ones are not used. To configure custom translations, the `USERLOG_TRANSLATION_PATH` environment variable needs to point to a base folder that will contain the translation files. This path must be available from all instances of the userlog service, a shared storage is recommended. Translation files must be of type [.po](https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html#PO-Files) or [.mo](https://www.gnu.org/software/gettext/manual/html_node/Binaries.html). For each language, the filename needs to be `userlog.po` (or `userlog.mo`) and stored in a folder structure defining the language code. In general the path/name pattern for a translation file needs to be:
|
||||
|
||||
```text
|
||||
{USERLOG_TRANSLATION_PATH}/{language-code}/LC_MESSAGES/userlog.po
|
||||
```
|
||||
|
||||
The language code pattern is composed of `language[_territory]` where `language` is the base language and `_territory` is optional and defines a country.
|
||||
|
||||
For example, for the language `de_DE`, one needs to place the corresponding translation files to `{USERLOG_TRANSLATION_PATH}/de_DE/LC_MESSAGES/userlog.po`.
|
||||
|
||||
### Translation Rules
|
||||
|
||||
* If a requested language code is not available, the service tries to fall back to the base language if available. For example, if `de_DE` is not available, the service tries to fall back to translations in the `de` folder.
|
||||
* If the base language `de` is also not available, the service falls back to the system's default English (`en`), which is the source of the texts provided by the code.
|
||||
@@ -1,18 +0,0 @@
|
||||
---
|
||||
title: "Web"
|
||||
date: 2018-05-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/web
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The web service embeds [ownCloud Web](https://github.com/owncloud/web) to provide a UI for ownCloud Infinite Scale.
|
||||
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,17 +0,0 @@
|
||||
---
|
||||
title: WebDAV
|
||||
date: 2018-05-02T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/webdav
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
This service provides preview (thumbnails) endpoints on the WebDAV API and therefore extends the main WebDAV API provided by the [oCDAV service]({{ ../../ocdav }}).
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
@@ -1,139 +0,0 @@
|
||||
---
|
||||
title: Webfinger
|
||||
date: 2023-02-03T00:00:00+00:00
|
||||
weight: 20
|
||||
geekdocRepo: https://github.com/owncloud/ocis
|
||||
geekdocEditPath: edit/master/docs/services/webfinger
|
||||
geekdocFilePath: _index.md
|
||||
geekdocCollapseSection: true
|
||||
---
|
||||
|
||||
## Abstract
|
||||
|
||||
The webfinger service provides an RFC7033 WebFinger lookup of ownCloud instances relevant for a given user account via endpoints a the /.well-known/webfinger implementation.
|
||||
|
||||
It is based on https://github.com/owncloud/lookup-webfinger-sciebo but also returns localized `titles` in addition to the `href` property.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
{{< toc-tree >}}
|
||||
|
||||
## OpenID Connect Discovery
|
||||
|
||||
Clients can make an unauthenticated `GET https://drive.ocis.test/.well-known/webfinger?resource=https%3A%2F%2Fcloud.ocis.test` request to discover the OpenID Connect Issuer in the `http://openid.net/specs/connect/1.0/issuer` relation:
|
||||
|
||||
```json
|
||||
{
|
||||
"subject": "acct:einstein@drive.ocis.test",
|
||||
"links": [
|
||||
{
|
||||
"rel": "http://openid.net/specs/connect/1.0/issuer",
|
||||
"href": "https://sso.example.org/cas/oidc/"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Here, the `resource` takes the instance domain URI, but an `acct:` URI works as well.
|
||||
|
||||
## Authenticated Instance Discovery
|
||||
|
||||
When using OpenID connect to authenticate requests, clients can look up the owncloud instances a user has access to.
|
||||
|
||||
* Authentication is necessary to prevent leaking information about existing users.
|
||||
* Basic auth is not supported.
|
||||
|
||||
The default configuration will simply return the `OCIS_URL` and direct clients to that domain:
|
||||
|
||||
```json
|
||||
{
|
||||
"subject": "acct:einstein@drive.ocis.test",
|
||||
"links": [
|
||||
{
|
||||
"rel": "http://openid.net/specs/connect/1.0/issuer",
|
||||
"href": "https://sso.example.org/cas/oidc/"
|
||||
},
|
||||
{
|
||||
"rel": "http://webfinger.owncloud/rel/server-instance",
|
||||
"href": "https://abc.drive.example.org",
|
||||
"titles": {
|
||||
"en": "oCIS Instance"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Configure Different Instances Based on OpenidConnect UserInfo Claims
|
||||
|
||||
A more complex example for configuring different instances could look like this:
|
||||
|
||||
```yaml
|
||||
webfinger:
|
||||
instances:
|
||||
- claim: email
|
||||
regex: einstein@example\.org
|
||||
href: "https://{{.preferred_username}}.cloud.ocis.test"
|
||||
title:
|
||||
"en": "oCIS Instance for Einstein"
|
||||
"de": "oCIS Instanz für Einstein"
|
||||
break: true
|
||||
- claim: "email"
|
||||
regex: marie@example\.org
|
||||
href: "https://{{.preferred_username}}.cloud.ocis.test"
|
||||
title:
|
||||
"en": "oCIS Instance for Marie"
|
||||
"de": "oCIS Instanz für Marie"
|
||||
break: false
|
||||
- claim: "email"
|
||||
regex: .+@example\.org
|
||||
href: "https://example-org.cloud.ocis.test"
|
||||
title:
|
||||
"en": "oCIS Instance for example.org"
|
||||
"de": "oCIS Instanz für example.org"
|
||||
break: true
|
||||
- claim: "email"
|
||||
regex: .+@example\.com
|
||||
href: "https://example-com.cloud.ocis.test"
|
||||
title:
|
||||
"en": "oCIS Instance for example.com"
|
||||
"de": "oCIS Instanz für example.com"
|
||||
break: true
|
||||
- claim: "email"
|
||||
regex: .+@.+\..+
|
||||
href: "https://cloud.ocis.test"
|
||||
title:
|
||||
"en": "oCIS Instance"
|
||||
"de": "oCIS Instanz"
|
||||
break: true
|
||||
```
|
||||
|
||||
Now, an authenticated webfinger request for `acct:me@example.org` (when logged in as marie) would return two instances, based on her `email` claim, the regex matches and break flags:
|
||||
|
||||
```json
|
||||
{
|
||||
"subject": "acct:marie@example.org",
|
||||
"links": [
|
||||
{
|
||||
"rel": "http://openid.net/specs/connect/1.0/issuer",
|
||||
"href": "https://sso.example.org/cas/oidc/"
|
||||
},
|
||||
{
|
||||
"rel": "http://webfinger.owncloud/rel/server-instance",
|
||||
"href": "https://marie.cloud.ocis.test",
|
||||
"titles": {
|
||||
"en": "oCIS Instance for Marie",
|
||||
"de": "oCIS Instanz für Marie"
|
||||
}
|
||||
},
|
||||
{
|
||||
"rel": "http://webfinger.owncloud/rel/server-instance",
|
||||
"href": "https://xyz.drive.example.org",
|
||||
"titles": {
|
||||
"en": "oCIS Instance for example.org",
|
||||
"de": "oCIS Instanz für example.org"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Reference in New Issue
Block a user