* fix: the public share configuration and fixed graceful shutdown
* fix: [OCISDEV-1433] remove GRPC_MAX_CONNECTION_AGE
The setting closed healthy grpc connections on a timer so that clients would redo
their DNS lookup. It never helped against the failure it was reached for - a
connection whose peer stopped answering - because the age limit is enforced by
the server, the grace period was left at infinity so a request already in flight
was never ended, and any value without a unit suffix silently disabled it again.
Detecting a peer that stops answering is now the job of the grpc clients, which
ping the peer while a request is in flight. The servers here got the matching
enforcement policy so they accept those pings; the client side arrives with the
next reva bump.
* fix: Added the new variable OCDAV_DISABLE_PROPFIND_PUBLIC_LINK_RESOLUTION that disable the resolution of public link shares when answering PROPFIND requests.
* chore: bump reva
* fix: The keepalive added to grpc clinet
* chore: bump reva
* build(deps): bump go 1.26.8, grpc-go dependency
---------
(cherry picked from commit e86eb4d210)
For the 9.0 branch, the reva dependency was pointed at reva's main-branch
merge of PR #748 (commit 373f9509a, pseudo-version
v2.0.0-20261005091647-373f9509a363) instead of the 8.2-targeted
e0beaa380005, since the 8.2 merge predates the VaultMode/UploadSessionFilter.Orphaned
APIs already present on the 9.0 reva lineage.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
# Conflicts:
# changelog/unreleased/security-bump-grpc.md
# go.mod
# go.sum
# vendor/google.golang.org/grpc/server.go
# vendor/google.golang.org/grpc/stream.go
# vendor/google.golang.org/grpc/version.go
# vendor/modules.txt
fix(graph): [OCISDEV-492] reject space images too large to be rendered
Setting a space image larger than the thumbnails service accepts appeared
to succeed but never changed the space image. Uploading the file and
assigning it as the space image are two separate requests, and both
completed successfully, so clients reported success. Only a later preview
request, which the assigning client never observes, was rejected because
the image exceeded THUMBNAILS_MAX_INPUT_IMAGE_FILE_SIZE. As space images
are rendered exclusively as thumbnails, the image was not merely degraded,
it was invisible with no error anywhere in the UI.
The graph service now stats the file when a space image is assigned and
rejects the request with 413 Request Entity Too Large instead of storing a
reference which cannot be displayed. The previous space image is left
untouched. The limit is read from the new GRAPH_MAX_IMAGE_FILE_SIZE
setting, which defaults to the value of
THUMBNAILS_MAX_INPUT_IMAGE_FILE_SIZE so that a single setting keeps both
services in agreement. A limit of zero disables the check. Space
descriptions (readme) are not affected.
* feat: metadata autopropagation
* feat: autoprop support for MFA / vault mode
* fix: replace some http clients with reva ones
* chore: required lib update
* fix: adjust unit tests and generate new mocks
* fix: apply autopropagation to all regular graph routes
* chore: updated reva dependency
* fix: return the right decorator for the thumbnails
* fix: remove autopropagation headers in the proxy
* feat: Implemet the vault-storage
feat: Separate the storage-users and graph to handle
feat: move the space create cache
configurate the vault srorage Postprocessing
hide the assignment of the MountID to VaultStorageProviderID behind a flag to avoid the ID mismatch
configurate the proxy to create the vault home space
update the filter
Make the graph able to handle vault prefix. no extra service needed
apply the vault filter to sharedbyme and sharedwithme
added vault-storage docker
use squashed reva
fix the finishUpload event
restict webdav copy/move from the vault
feat: provide the mfa to webdav and grpc
feat: refactoring: provide the mfa to webdav and grpc
mfa collaboration
fix GetRootDriveChildren and more
fix: send the MFA header in HTTP clients from the collaboration service
provide the default storage user vault configuration
update create_home middleware
Update deployments/examples/ocis_full/vault-storage.yml
Co-authored-by: Martin <github@diemattels.at>
Update services/gateway/pkg/config/config.go
Co-authored-by: Martin <github@diemattels.at>
Update services/graph/pkg/config/config.go
Co-authored-by: Martin <github@diemattels.at>
Update services/graph/pkg/config/config.go
Co-authored-by: Martin <github@diemattels.at>
Update services/storage-users/pkg/config/config.go
Co-authored-by: Martin <github@diemattels.at>
Update services/proxy/pkg/config/config.go
Co-authored-by: Martin <github@diemattels.at>
Update services/storage-users/pkg/config/config.go
Co-authored-by: Martin <github@diemattels.at>
Update deployments/examples/ocis_full/vault-storage.yml
Co-authored-by: Martin <github@diemattels.at>
bump reva
deduplicate the requireMFA middeware on vault routes. fix AppendPlainToOpaque.
added the changlog and comments
* feat: add the vault mode search
* Update changelog/unreleased/enhancement-vault-storage.md
Co-authored-by: Martin <github@diemattels.at>
* update the readme. the reva vault storage provider configuration disabled by default
* feat: [OCISDEV-531] add vault capabilities to the OCS capabilities endpoint
* the port range allocated. the configuration updated.
---------
Co-authored-by: Martin <github@diemattels.at>
otelchi and other custom solutions have been replaced with otelhttp to
trace HTTP requests; new middleware is provided to be used across the
platform.
The proxy service will use a custom HTTP client to forward the headers
needed for telemetry automatically (also based on otelhttp)
The "tracing.GetNewRequest" and "tracing.GetNewRequestWithContext" aims
to replace the "http.NewRequest" and "http.NewRequestWithContext"
respectively by including tracing data.
For requests that have been already created, such as the case of some
reva requests, "tracing.InjectTracingHeaders" is provided.
Note that some outgoing requests might be required NOT to use tracing
headers.
For GeoGebra files we where still using the imaging package to decode the
embedded png, but handed it of to vips for scaling, which can't work. Now
we use vips for decoding the image as well.
This moves the ratelimit ('THUMBNAILS_MAX_CONCURRENT_REQUESTS') from the
HTTP endpoint to the GRPC endpoint. The HTTP endpoint is just used for
downloading already created thumbnails. But the resource consuming part of
thumbnail generation happens in the GRPC service.
