sevenhill/QSfera
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into update-bridge-docs

Browse Source
This commit is contained in:
A.Unger
2021-09-29 12:09:29 +02:00
parent 5554c72d9a f36017f188
commit 6166bb5a4c
511 changed files with 12687 additions and 17566 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/extensions/graph/spaces.md
+257
View File
@@ -0,0 +1,257 @@
---
title: Spaces
weight: 20
geekdocRepo: https://github.com/owncloud/ocis
geekdocEditPath: edit/master/docs/extensions/graph
geekdocFilePath: spaces.md
---
{{< toc >}}
## Graph Service
The Graph service is a reference implementation of the MS Graph API. There are no libraries doing any work only a set of routes and handlers.
## Spaces API
The Spaces API makes use of the [MS Graph API Drive resource](https://docs.microsoft.com/en-us/graph/api/resources/drive?view=graph-rest-1.0) to represent the concept of a Storage Space. Natively the MS Graph Specification [does not provide a way for creating Drives](https://docs.microsoft.com/en-us/graph/api/resources/drive?view=graph-rest-1.0#methods), as a Drive is a read only resource.
We circumvented this limitation by adding a `POST /drive/{drive-name}` to the Graph router. A major drawback of this solution is that this endpoint does not have support from the official MS Graph SDK, however it is reachable by any HTTP clients.
### Methods
```
POST /drive/{drive-name}
```
Calls to the following endpoint will create a Space with all the default parameters since we do not parse the request body just yet.
## Examples
We can now create a `Marketing` space and retrieve its WebDAV endpoint. Let's see how to do this.
### Starting conditions
This is the status of a DecomposedFS `users` tree. As we can see it is empty because we have not yet logged in with any users. It is a fresh new installation.
```
❯ tree -a /var/tmp/ocis/storage/users
/var/tmp/ocis/storage/users
├── blobs
├── nodes
│ └── root
├── spaces
│ ├── personal
│ └── share
├── trash
└── uploads
```
Let's start with creating a space:
`curl -k -X POST 'https://localhost:9200/graph/v1.0/drives/marketing' -u einstein:relativity -v`
```
❯ tree -a /var/tmp/ocis/storage/users
/var/tmp/ocis/storage/users
├── blobs
├── nodes
│ ├── 02dc1ec5-28b5-41c5-a48a-fabd4fa0562e
│ │ └── .space -> ../e85d185f-cdaa-4618-a312-e33ea435acfe
│ ├── 52efe3c2-c95a-47a1-8f3d-924aa473c711
│ ├── e85d185f-cdaa-4618-a312-e33ea435acfe
│ └── root
│ ├── 4c510ada-c86b-4815-8820-42cdf82c3d51 -> ../52efe3c2-c95a-47a1-8f3d-924aa473c711
│ └── c42debb8-926e-4a46-83b0-39dba56e59a4 -> ../02dc1ec5-28b5-41c5-a48a-fabd4fa0562e
├── spaces
│ ├── personal
│ │ └── 52efe3c2-c95a-47a1-8f3d-924aa473c711 -> ../../nodes/52efe3c2-c95a-47a1-8f3d-924aa473c711
│ ├── project
│ │ └── 02dc1ec5-28b5-41c5-a48a-fabd4fa0562e -> ../../nodes/02dc1ec5-28b5-41c5-a48a-fabd4fa0562e
│ └── share
├── trash
└── uploads
```
we can see that the `project` folder was added to the spaces as well as the `.space` folder to the space node `02dc1ec5-28b5-41c5-a48a-fabd4fa0562e`. For demonstration purposes, let's list the extended attributes of the new node:
```
xattr -l /var/tmp/ocis/storage/users/nodes/root/c42debb8-926e-4a46-83b0-39dba56e59a4
user.ocis.blobid:
user.ocis.blobsize: 0
user.ocis.name: c42debb8-926e-4a46-83b0-39dba56e59a4
user.ocis.owner.id: 4c510ada-c86b-4815-8820-42cdf82c3d51
user.ocis.owner.idp: https://localhost:9200
user.ocis.owner.type: primary
user.ocis.parentid: root
user.ocis.quota: 65536
user.ocis.space.name: marketing
```
As seen here it contains the metadata from the default list of requirements for this ticket.
Let's list the drive we just created using the graph API:
```
curl -k 'https://localhost:9200/graph/v1.0/me/drives' -u einstein:relativity -v | jq .value
[
{
"driveType": "personal",
"id": "1284d238-aa92-42ce-bdc4-0b0000009157!52efe3c2-c95a-47a1-8f3d-924aa473c711",
"lastModifiedDateTime": "2021-09-07T14:42:39.025050471+02:00",
"name": "root",
"owner": {
"user": {
"id": "4c510ada-c86b-4815-8820-42cdf82c3d51"
}
},
"root": {
"id": "1284d238-aa92-42ce-bdc4-0b0000009157!52efe3c2-c95a-47a1-8f3d-924aa473c711",
"webDavUrl": "https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157!52efe3c2-c95a-47a1-8f3d-924aa473c711"
}
},
{
"driveType": "project",
"id": "1284d238-aa92-42ce-bdc4-0b0000009157!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e",
"lastModifiedDateTime": "2021-09-07T14:42:39.030705579+02:00",
"name": "root",
"owner": {
"user": {
"id": "4c510ada-c86b-4815-8820-42cdf82c3d51"
}
},
"quota": {
"total": 65536
},
"root": {
"id": "1284d238-aa92-42ce-bdc4-0b0000009157!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e",
"webDavUrl": "https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e"
}
}
]
As we can see the response already contains a space-aware dav endpoint, which we can use to upload files to the space:
```
curl -k https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157\!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e/test.txt -X PUT -d "beep-sboop" -v -u einstein:relativity
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 9200 (#0)
* upload completely sent off: 10 out of 10 bytes
< HTTP/1.1 201 Created
< Access-Control-Allow-Origin: *
< Content-Length: 0
< Content-Security-Policy: default-src 'none';
< Content-Type: text/plain
< Date: Tue, 07 Sep 2021 12:45:54 GMT
< Etag: "e2942565a4eb52e8754c2806f215fe93"
< Last-Modified: Tue, 07 Sep 2021 12:45:54 +0000
< Oc-Etag: "e2942565a4eb52e8754c2806f215fe93"
< Oc-Fileid: MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmU4ZDIwNDA5LTE1OWItNGI2Ny1iODZkLTlkM2U3ZjYyYmM0ZQ==
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-Download-Options: noopen
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: none
< X-Xss-Protection: 1; mode=block
<
* Connection #0 to host localhost left intact
* Closing connection 0
```
This is the state after every transformation:
```
tree -a /var/tmp/ocis/storage/users
/var/tmp/ocis/storage/users
├── blobs
│ └── 83842d56-91de-41d5-8800-b2fb7b2d31cf
├── nodes
│ ├── 02dc1ec5-28b5-41c5-a48a-fabd4fa0562e
│ │ ├── .space -> ../e85d185f-cdaa-4618-a312-e33ea435acfe
│ │ └── test.txt -> ../e8d20409-159b-4b67-b86d-9d3e7f62bc4e
│ ├── 52efe3c2-c95a-47a1-8f3d-924aa473c711
│ ├── e85d185f-cdaa-4618-a312-e33ea435acfe
│ ├── e8d20409-159b-4b67-b86d-9d3e7f62bc4e
│ └── root
│ ├── 4c510ada-c86b-4815-8820-42cdf82c3d51 -> ../52efe3c2-c95a-47a1-8f3d-924aa473c711
│ └── c42debb8-926e-4a46-83b0-39dba56e59a4 -> ../02dc1ec5-28b5-41c5-a48a-fabd4fa0562e
├── spaces
│ ├── personal
│ │ └── 52efe3c2-c95a-47a1-8f3d-924aa473c711 -> ../../nodes/52efe3c2-c95a-47a1-8f3d-924aa473c711
│ ├── project
│ │ └── 02dc1ec5-28b5-41c5-a48a-fabd4fa0562e -> ../../nodes/02dc1ec5-28b5-41c5-a48a-fabd4fa0562e
│ └── share
├── trash
└── uploads
```
Observe the `test.txt` in the `02dc1ec5-28b5-41c5-a48a-fabd4fa0562e` node.
To finalize, verify the new created file is webdav-listable:
```xml
curl -k https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157\!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e -X PROPFIND -v -u einstein:relativity | xmllint --format -
<?xml version="1.0" encoding="utf-8"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
<d:response>
<d:href>/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e/</d:href>
<d:propstat>
<d:prop>
<oc:id>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OjAyZGMxZWM1LTI4YjUtNDFjNS1hNDhhLWZhYmQ0ZmEwNTYyZQ==</oc:id>
<oc:fileid>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OjAyZGMxZWM1LTI4YjUtNDFjNS1hNDhhLWZhYmQ0ZmEwNTYyZQ==</oc:fileid>
<d:getetag>"35a2ce5f56592d79d1b7233eff033347"</d:getetag>
<oc:permissions>RDNVCK</oc:permissions>
<d:resourcetype>
<d:collection/>
</d:resourcetype>
<oc:size>0</oc:size>
<d:getlastmodified>Tue, 07 Sep 2021 12:45:54 GMT</d:getlastmodified>
<oc:favorite>0</oc:favorite>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
<d:response>
<d:href>/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e/.space/</d:href>
<d:propstat>
<d:prop>
<oc:id>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmU4NWQxODVmLWNkYWEtNDYxOC1hMzEyLWUzM2VhNDM1YWNmZQ==</oc:id>
<oc:fileid>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmU4NWQxODVmLWNkYWEtNDYxOC1hMzEyLWUzM2VhNDM1YWNmZQ==</oc:fileid>
<d:getetag>"2e9a84bffce8b648ba626185800ee8fa"</d:getetag>
<oc:permissions>SRDNVCK</oc:permissions>
<d:resourcetype>
<d:collection/>
</d:resourcetype>
<oc:size>0</oc:size>
<d:getlastmodified>Tue, 07 Sep 2021 12:42:39 GMT</d:getlastmodified>
<oc:favorite>0</oc:favorite>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
<d:response>
<d:href>/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157!02dc1ec5-28b5-41c5-a48a-fabd4fa0562e/test.txt</d:href>
<d:propstat>
<d:prop>
<oc:id>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmU4ZDIwNDA5LTE1OWItNGI2Ny1iODZkLTlkM2U3ZjYyYmM0ZQ==</oc:id>
<oc:fileid>MTI4NGQyMzgtYWE5Mi00MmNlLWJkYzQtMGIwMDAwMDA5MTU3OmU4ZDIwNDA5LTE1OWItNGI2Ny1iODZkLTlkM2U3ZjYyYmM0ZQ==</oc:fileid>
<d:getetag>"e2942565a4eb52e8754c2806f215fe93"</d:getetag>
<oc:permissions>RDNVW</oc:permissions>
<d:resourcetype/>
<d:getcontentlength>10</d:getcontentlength>
<d:getcontenttype>text/plain</d:getcontenttype>
<d:getlastmodified>Tue, 07 Sep 2021 12:45:54 GMT</d:getlastmodified>
<oc:checksums>
<oc:checksum>SHA1:8f4b4c83c565fc5ec54b78c30c94a6b65e411de5 MD5:6a3a4eca9a6726eef8f7be5b03ea9011 ADLER32:151303ed</oc:checksum>
</oc:checksums>
<oc:favorite>0</oc:favorite>
</d:prop>
<d:status>HTTP/1.1 200 OK</d:status>
</d:propstat>
</d:response>
</d:multistatus>
```
docs/extensions/onlyoffice/.gitignore
-2
View File
@@ -1,2 +0,0 @@
configuration.md
grpc.md
docs/extensions/onlyoffice/_index.md
-11
View File
@@ -1,11 +0,0 @@
---
title: "OnlyOffice"
date: 2018-05-02T00:00:00+00:00
weight: 20
geekdocRepo: https://github.com/owncloud/ocis
geekdocEditPath: edit/master/docs/extensions/onlyoffice
geekdocFilePath: _index.md
geekdocCollapseSection: true
---
This service enables users open documents, spreadsheets and presentations in the OnlyOffice app installed in ownCloud 10.
docs/extensions/onlyoffice/building.md
-28
View File
@@ -1,28 +0,0 @@
---
title: "Building"
date: 2018-05-02T00:00:00+00:00
weight: 30
geekdocRepo: https://github.com/owncloud/ocis
geekdocEditPath: edit/master/docs/extensions/onlyoffice
geekdocFilePath: building.md
---
{{< toc >}}
As this project is built with Go, so you need to install that first. The installation of Go is out of the scope of this document, please follow the official documentation for [Go](https://golang.org/doc/install), to build this project you have to install Go >= v1.12. After the installation of the required tools you need to get the sources:
{{< highlight txt >}}
git clone https://github.com/owncloud/ocis/onlyoffice.git
cd ocis-onlyoffice
{{< / highlight >}}
All required tool besides Go itself and make are bundled or getting automatically installed within the `GOPATH`. All commands to build this project are part of our `Makefile`.
## Backend
{{< highlight txt >}}
make generate
make build
{{< / highlight >}}
Finally you should have the binary within the `bin/` folder now, give it a try with `./bin/onlyoffice -h` to see all available options.
docs/extensions/onlyoffice/getting-started.md
-291
View File
@@ -1,291 +0,0 @@
---
title: "Getting Started"
date: 2018-05-02T00:00:00+00:00
weight: 20
geekdocRepo: https://github.com/owncloud/ocis
geekdocEditPath: edit/master/docs/extensions/onlyoffice
geekdocFilePath: getting-started.md
---
{{< toc >}}
## Installation
So far we are offering two different variants for the installation. You can choose between [Docker](https://www.docker.com/) or pre-built binaries which are stored on our download mirrors and GitHub releases. Maybe we will also provide system packages for the major distributions later if we see the need for it.
### Docker
TBD
### Binaries
TBD
## Configuration
We provide overall three different variants of configuration. The variant based on environment variables and commandline flags are split up into global values and command-specific values.
### ownCloud Web configuration
When loading the extension in the ownCloud Web, it is necessary to specify to which ownCloud 10 server the extension is supposed to connect to. This can be done via `config` object when registering the extension in `config.json`. For more details, you can take a look at the following example:
```json
"external_apps": [
{
"id": "onlyoffice",
"path": "https://localhost:9200/onlyoffice.js",
"config": {
"server": "https://oc10.example.org"
}
}
]
```
### Environment variables
If you prefer to configure the service with environment variables you can see the available variables below.
#### Global
ONLYOFFICE_CONFIG_FILE
: Path to config file, empty default value
ONLYOFFICE_LOG_LEVEL
: Set logging level, defaults to `info`
ONLYOFFICE_LOG_COLOR
: Enable colored logging, defaults to `true`
ONLYOFFICE_LOG_PRETTY
: Enable pretty logging, defaults to `true`
#### Server
ONLYOFFICE_TRACING_ENABLED
: Enable sending traces, defaults to `false`
ONLYOFFICE_TRACING_TYPE
: Tracing backend type, defaults to `jaeger`
ONLYOFFICE_TRACING_ENDPOINT
: Endpoint for the agent, empty default value
ONLYOFFICE_TRACING_COLLECTOR
: Endpoint for the collector, empty default value
ONLYOFFICE_TRACING_SERVICE
: Service name for tracing, defaults to `onlyoffice`
ONLYOFFICE_DEBUG_ADDR
: Address to bind debug server, defaults to `0.0.0.0:9224`
ONLYOFFICE_DEBUG_TOKEN
: Token to grant metrics access, empty default value
ONLYOFFICE_DEBUG_PPROF
: Enable pprof debugging, defaults to `false`
ONLYOFFICE_DEBUG_ZPAGES
: Enable zpages debugging, defaults to `false`
ONLYOFFICE_HTTP_ADDR
: Address to bind http server, defaults to `0.0.0.0:9220`
ONLYOFFICE_HTTP_NAMESPACE
: The http namespace
ONLYOFFICE_HTTP_ROOT
: Root path of http server, defaults to `/`
#### Health
ONLYOFFICE_DEBUG_ADDR
: Address to debug endpoint, defaults to `0.0.0.0:9224`
### Commandline flags
If you prefer to configure the service with commandline flags you can see the available variables below.
#### Global
--config-file | $ONLYOFFICE_CONFIG_FILE
: Path to config file.
--log-level | $ONLYOFFICE_LOG_LEVEL
: Set logging level. Default: `info`.
--log-pretty | $ONLYOFFICE_LOG_PRETTY
: Enable pretty logging. Default: `true`.
--log-color | $ONLYOFFICE_LOG_COLOR
: Enable colored logging. Default: `true`.
#### Server
--tracing-enabled | $ONLYOFFICE_TRACING_ENABLED
: Enable sending traces.
--tracing-type | $ONLYOFFICE_TRACING_TYPE
: Tracing backend type. Default: `jaeger`.
--tracing-endpoint | $ONLYOFFICE_TRACING_ENDPOINT
: Endpoint for the agent.
--tracing-collector | $ONLYOFFICE_TRACING_COLLECTOR
: Endpoint for the collector.
--tracing-service | $ONLYOFFICE_TRACING_SERVICE
: Service name for tracing. Default: `onlyoffice`.
--debug-addr | $ONLYOFFICE_DEBUG_ADDR
: Address to bind debug server. Default: `0.0.0.0:9224`.
--debug-token | $ONLYOFFICE_DEBUG_TOKEN
: Token to grant metrics access.
--debug-pprof | $ONLYOFFICE_DEBUG_PPROF
: Enable pprof debugging.
--debug-zpages | $ONLYOFFICE_DEBUG_ZPAGES
: Enable zpages debugging.
--http-addr | $ONLYOFFICE_HTTP_ADDR
: Address to bind http server. Default: `0.0.0.0:9220`.
--http-namespace | $ONLYOFFICE_HTTP_NAMESPACE
: Set the base namespace for the http namespace. Default: `com.owncloud.web`.
--http-root | $ONLYOFFICE_HTTP_ROOT
: Root path of http server. Default: `/`.
--asset-path | $ONLYOFFICE_ASSET_PATH
: Path to custom assets.
#### Health
--debug-addr | $ONLYOFFICE_DEBUG_ADDR
: Address to debug endpoint. Default: `0.0.0.0:9224`.
### Configuration file
So far we support the file formats `JSON` and `YAML`, if you want to get a full example configuration just take a look at [our repository](https://github.com/owncloud/ocis/tree/master/onlyoffice/config), there you can always see the latest configuration format. These example configurations include all available options and the default values. The configuration file will be automatically loaded if it's placed at `/etc/ocis/onlyoffice.yml`, `${HOME}/.ocis/onlyoffice.yml` or `$(pwd)/config/onlyoffice.yml`.
## Usage
The program provides a few sub-commands on execution. The available configuration methods have already been mentioned above. Generally you can always see a formatted help output if you execute the binary via `ocis-onlyoffice --help`.
### Server
The server command is used to start the http and debug server on two addresses within a single process. The http server is serving the general webservice while the debug server is used for health check, readiness check and to server the metrics mentioned below. For further help please execute:
{{< highlight txt >}}
ocis-onlyoffice server --help
{{< / highlight >}}
### Health
The health command is used to execute a health check, if the exit code equals zero the service should be up and running, if the exist code is greater than zero the service is not in a healthy state. Generally this command is used within our Docker containers, it could also be used within Kubernetes.
{{< highlight txt >}}
ocis-onlyoffice health --help
{{< / highlight >}}
## Metrics
This service provides some [Prometheus](https://prometheus.io/) metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which got to be configured through one of the flag `--debug-token` or the environment variable `ONLYOFFICE_DEBUG_TOKEN` mentioned above. By default the metrics endpoint is bound to `http://0.0.0.0:9224/metrics`.
go_gc_duration_seconds
: A summary of the GC invocation durations
go_gc_duration_seconds_sum
: A summary of the GC invocation durations
go_gc_duration_seconds_count
: A summary of the GC invocation durations
go_goroutines
: Number of goroutines that currently exist
go_info
: Information about the Go environment
go_memstats_alloc_bytes
: Number of bytes allocated and still in use
go_memstats_alloc_bytes_total
: Total number of bytes allocated, even if freed
go_memstats_buck_hash_sys_bytes
: Number of bytes used by the profiling bucket hash table
go_memstats_frees_total
: Total number of frees
go_memstats_gc_cpu_fraction
: The fraction of this program's available CPU time used by the GC since the program started
go_memstats_gc_sys_bytes
: Number of bytes used for garbage collection system metadata
go_memstats_heap_alloc_bytes
: Number of heap bytes allocated and still in use
go_memstats_heap_idle_bytes
: Number of heap bytes waiting to be used
go_memstats_heap_inuse_bytes
: Number of heap bytes that are in use
go_memstats_heap_objects
: Number of allocated objects
go_memstats_heap_released_bytes
: Number of heap bytes released to OS
go_memstats_heap_sys_bytes
: Number of heap bytes obtained from system
go_memstats_last_gc_time_seconds
: Number of seconds since 1970 of last garbage collection
go_memstats_lookups_total
: Total number of pointer lookups
go_memstats_mallocs_total
: Total number of mallocs
go_memstats_mcache_inuse_bytes
: Number of bytes in use by mcache structures
go_memstats_mcache_sys_bytes
: Number of bytes used for mcache structures obtained from system
go_memstats_mspan_inuse_bytes
: Number of bytes in use by mspan structures
go_memstats_mspan_sys_bytes
: Number of bytes used for mspan structures obtained from system
go_memstats_next_gc_bytes
: Number of heap bytes when next garbage collection will take place
go_memstats_other_sys_bytes
: Number of bytes used for other system allocations
go_memstats_stack_inuse_bytes
: Number of bytes in use by the stack allocator
go_memstats_stack_sys_bytes
: Number of bytes obtained from system for stack allocator
go_memstats_sys_bytes
: Number of bytes obtained from system
go_threads
: Number of OS threads created
promhttp_metric_handler_requests_in_flight
: Current number of scrapes being served
promhttp_metric_handler_requests_total
: Total number of scrapes by HTTP status code
docs/extensions/onlyoffice/license.md
-10
View File
@@ -1,10 +0,0 @@
---
title: "License"
date: 2018-05-02T00:00:00+00:00
weight: 40
geekdocRepo: https://github.com/owncloud/ocis
geekdocEditPath: edit/master/docs/extensions/onlyoffice
geekdocFilePath: license.md
---
This project is licensed under the [Apache 2.0](https://github.com/owncloud/ocis/blob/master/onlyoffice/LICENSE) license. For the license of the used libraries you have to check the respective sources.
docs/extensions/storage/_index.md
+1 -1
View File
@@ -26,7 +26,7 @@ The dashed lines in the diagram indicate requests that are made to authenticate
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.
{{< hint warning >}}
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 seperate metadata necessary for running the service from data that is being served directly.
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.
{{< /hint >}}
## Endpoints and references
docs/extensions/storage/architecture.md
+1 -1
View File
@@ -89,7 +89,7 @@ The OCS service makes a stat request to the storage provider to get a [ResourceI
{{< hint >}}
The user and public share provider implementations identify the file using the [`ResourceId`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId). The [`ResourceInfo`](https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceInfo) is passed so the share provider can also store who the owner of the resource is. The *path* is not part of the other API calls, e.g. when listing shares.
The OCM API takes an id based reference on the CS3 api, even if the OCM HTTP endpoint takes a path argument. *@jfd: Why? Does it not need the owner? It only stores the owner of the share, which is always the currently looged in user, when creating a share. Afterwards only the owner can update a share ... so collaborative management of shares is not possible. At least for OCM shares.*
The OCM API takes an id based reference on the CS3 api, even if the OCM HTTP endpoint takes a path argument. *@jfd: Why? Does it not need the owner? It only stores the owner of the share, which is always the currently logged in user, when creating a share. Afterwards only the owner can update a share ... so collaborative management of shares is not possible. At least for OCM shares.*
{{< /hint >}}
### User and Group provisioning
docs/extensions/storage/ports.md
+2
View File
@@ -34,6 +34,8 @@ For now, the storage service uses these ports to preconfigure those services:
| 9159 | storage users debug |
| 9160 | groups |
| 9161 | groups debug |
| 9164 | storage appprovider |
| 9165 | storage appprovider debug |
| 9178 | storage public link |
| 9179 | storage public link data |
| 9215 | storage meta grpc |
docs/extensions/storage/terminology.md
+4 -4
View File
@@ -79,13 +79,13 @@ It maps the *path* and *id* based CS3 *references* to an appropriate [*storage s
{{< hint warning >}}
**Proposed Change**
iOS clients can only queue single requests to be executed in the background. The queue an upload and need to be able to identify the uploaded file after it has been uploaded to the server. The disconnected nature of the connection might cause worksflows or manual user interaction with the file on the server to move the file to a different place or changing the content while the device is offline. However, on the device users might have marked the file as favorite or added it to other iOS specific collections. To be able to reliably identify the file the client can generate a `uuid` and attach it to the file metadata during the upload. While it is not necessary to look up files by this `uuid` having a second file id that serves exactly the same purpose as the `file id` is redundant.
iOS clients can only queue single requests to be executed in the background. The queue an upload and need to be able to identify the uploaded file after it has been uploaded to the server. The disconnected nature of the connection might cause workflows or manual user interaction with the file on the server to move the file to a different place or changing the content while the device is offline. However, on the device users might have marked the file as favorite or added it to other iOS specific collections. To be able to reliably identify the file the client can generate a `uuid` and attach it to the file metadata during the upload. While it is not necessary to look up files by this `uuid` having a second file id that serves exactly the same purpose as the `file id` is redundant.
Another aspect for the `file id` / `uuid` is that it must be a logical identifier that can be set, at least by internal systems. Without a writeable fileid we cannot restore backups or migrate storage spaces from one storage provider to another storage provider.
Technically, this means that every storage driler needs to have a map of a `uuid` to in internal resource identifier. This internal resource identifier can be
Technically, this means that every storage driver needs to have a map of a `uuid` to in internal resource identifier. This internal resource identifier can be
- an eos fileid, because eos can look up files by id
- an inode if the filesystem and the storage driver support lookung up by inode
- an inode if the filesystem and the storage driver support looking up by inode
- a path if the storage driver has no way of looking up files by id.
- In this case other mechanisms like inotify, kernel audit or a fuse overlay might be used to keep the paths up to date.
- to prevent excessive writes when deep folders are renamed a reverse map might be used: it will map the `uuid` to `<parentuuid>:<childname>`, allowing to trade writes for reads
@@ -142,7 +142,7 @@ Examples would be every user's home storage space, project storage spaces or gro
Finally, a logical `storage space id` is not tied to a specific [*storage provider*]({{< ref "#storage-providers" >}}). If the [*storage driver*]({{< ref "#storage-drivers" >}}) supports it, we can import existing files including their `file id`, which makes it possible to move [*storage spaces*]({{< ref "#storage-spaces" >}}) between [*storage providers*]({{< ref "#storage-providers" >}}) to implement storage classes, e.g. with or without archival, workflows, on SSDs or HDDs.
## Shares
*To be clarified: we are aware that [*storage spaces*]({{< ref "#storage-spaces" >}}) may be too 'heavywheight' for ad hoc sharing with groups. That being said, there is no technical reason why group shares should not be treated like [*storage spaces*]({{< ref "#storage-spaces" >}}) that users can provision themselves. They would share the quota with the users home [*storage space*]({{< ref "#storage-spaces" >}}) and the share initiator would be the sole owner. Technically, the mechanism of treating a share like a new [*storage space*]({{< ref "#storage-spaces" >}}) would be the same. This obviously also extends to user shares and even file indvidual shares that would be wrapped in a virtual collection. It would also become possible to share collections of arbitrary files in a single storage space, e.g. the ten best pictures from a large album.*
*To be clarified: we are aware that [*storage spaces*]({{< ref "#storage-spaces" >}}) may be too 'heavyweight' for ad hoc sharing with groups. That being said, there is no technical reason why group shares should not be treated like [*storage spaces*]({{< ref "#storage-spaces" >}}) that users can provision themselves. They would share the quota with the users home [*storage space*]({{< ref "#storage-spaces" >}}) and the share initiator would be the sole owner. Technically, the mechanism of treating a share like a new [*storage space*]({{< ref "#storage-spaces" >}}) would be the same. This obviously also extends to user shares and even file individual shares that would be wrapped in a virtual collection. It would also become possible to share collections of arbitrary files in a single storage space, e.g. the ten best pictures from a large album.*
## Storage Systems