Repository navigation
Thumbnailer should use a push based mechanism #1128
Description
The current thumnailer uses a pull based mechanism that fetches an image via CS3+webdav from an internal space and then generates a thumbnail for it.
This requires the thumbnailer service to make requests to other services, which opens up attack vectors in case it gets compromised. Unfortunately creating thumnails requires interpreting user provided bytes, which is a well known attack vector.
In contrast, the antivirus and search service send a byte stream to clamav / tika and get a corresponding response. This allows locking down any container that runs clamav or tika and forbid them from making any external requests.
Our thumbnailer service should work in the same way and make a plain http call to another container/pod/service.
In large deployments the clamav, tika and imagor services could then be shared by all instances and scaled based on load, regardless of any instance health.
We could use https://github.com/cshum/imagor, a Fast, secure image processing server and Go library, using libvips. While it uses the thumbor API it has no way to POST an image, yet: cshum/imagor#383 (comment) We might help with that ... after we do an audit of this dependency, as it seems to be from Hong Kong.
Imagor can cache images on an S3 bucket and there is also https://github.com/cshum/imagorvideo for video thumbnails.
We can use the https://hub.docker.com/r/shumc/imagor/ docker container, which even supports HEIC.
Activity
butonic commentedon Jun 27, 2025
There are altenatives;
micbar commentedon Jun 27, 2025
This is not entirely true 😄 These services are downloading the bytes from the dataprovider because they are subscribing to an event.
butonic commentedon Jun 27, 2025
yes, antivirus and search 'download' bytes via cs3, but then they send them to clamav/tika. The latter do not make any requests to the outside.
butonic commentedon Jun 30, 2026
imagor supports push since 2025: cshum/imagor#383 (comment)
tbsbdr commentedon Jun 30, 2026
PB
butonic commentedon Jun 30, 2026
Our internal implementation could be changed to POST images to the thumbnailer service. imagor might even be embedded in the binary, as it is written in go. For compose / helm we can exchange the implementation as there are at least two image proxies supporting the same thumbor API:
Both seem to be well maintained and a docker container is available as well. This allows changing the implementation (and supporting e.g. HEIC) by switching to a different docker container. We need to find out if we can compile a binary that embeds imagor without HEIC support to avoid #630 (comment)
The deployment cost for large instances might be reduced, because multiple instances can share the same thumbnailer service. It is stateless and can cache thumbnails in an s3 bucket.
dschmidt commentedon Aug 19, 2026
I cannot make too much sense of this. Wouldnt anyone still need to implement the endpoint to then post it to the service?
Would you move the pushing to imgor (or whatever) into the webdav service then?
dschmidt commentedon Aug 19, 2026
Additional question:
Would you keep the caching mechanism inside OpenCloud or use the builtin caching?
If the cache lives only in imagor, we need to proxy every thumbnail request to it, which might add some more latency and fragility when serving thumbnail requests (especially not only on the first request)
Tika runs async anyway, so it's less of a consideration there
Not arguing against anything, just saying we should be fully aware of consequences
rhafer commentedon Aug 20, 2026
AFAICS imagor doesn't do any caching/storing when using POST/upload for image processing. So caching would still have to happen in OpenCloud.
dschmidt commentedon Aug 20, 2026
That's actually perfect, as it allows easier integration of other services for other formats (see my updated #3332 and the possible followup #3362).
Also our caching mechanism is already battle tested, so 👍
guruz commentedon Oct 15, 2026
Dumping this here just as inspiration:
This avoids security or scaling issues :-) (in theory...)