Note: logs and reproduction steps are from my own instance. The write-up and
research were done with AI assistance.
Steps to reproduce
- Create a folder in a personal space containing several non-previewable files (e.g. ~8 PDF and DOCX files) plus one JPG.
- Open the folder in the web UI and observe the server access log — a preview is requested only for the JPG.
- Open the same folder in the iOS app and observe the server access log — a preview is requested for every file, and several files are requested twice.
Expected behavior
The iOS app should filter by mime type before requesting thumbnails, the way the web client does, and should not issue duplicate preview requests for the same file within a single folder load.
Actual behavior
The iOS app requests ?preview=1 for every file in the folder regardless of type. The thumbnails service cannot generate previews for PDF or DOCX, so each request returns HTTP 404 (documented behavior). Opening one folder of ~8 documents produces 12+ 404 responses within roughly 2 seconds.
This is enough to trip intrusion detection watching the reverse proxy. In my case CrowdSec's crowdsecurity/http-probing scenario fired on 11 events and issued a 7-day IP ban. Because the ban is enforced at the reverse proxy, it blocks every service behind that proxy, not just OpenCloud. Each subsequent app refresh re-triggers the ban immediately, so the app is effectively unusable from outside a whitelisted network.
Differences observed between the two clients against the same folder and server:
| |
web |
iOS |
| requested size |
x=36&y=36 |
x=180&y=180 |
| processor parameter |
thumbnail |
absent |
| file types requested |
images only |
all types |
| duplicate requests |
no |
yes |
Client
OpenCloud app version: 1.2.3
Server configuration
OpenCloud version: 7.4.0
Deployment: Docker Compose, external reverse proxy (Traefik), external OIDC provider (Authelia), default POSIX storage driver.
Logs
OpenCloud server error log
Web client — one preview request, image only:
GET /dav/spaces/<SPACE_ID>/<IMAGE>.jpg?scalingup=0&preview=1&a=1&processor=thumbnail&c=<HASH>&x=36&y=36 HTTP/2.0" 200 5183
No preview requests were issued for the PDF/DOCX files in the same folder listing.
iOS app — one preview request per file, all types, with duplicates:
GET /dav/spaces/<SPACE_ID>/<FILE_A>.docx?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 263
GET /dav/spaces/<SPACE_ID>/<FILE_B>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 317
GET /dav/spaces/<SPACE_ID>/<FILE_C>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 244
GET /dav/spaces/<SPACE_ID>/<FILE_A>.docx?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 263 <-- duplicate
GET /dav/spaces/<SPACE_ID>/<FILE_D>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 271
GET /dav/spaces/<SPACE_ID>/<FILE_E>.docx?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 253
GET /dav/spaces/<SPACE_ID>/<FILE_B>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 317 <-- duplicate
GET /dav/spaces/<SPACE_ID>/<FILE_F>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 261
GET /dav/spaces/<SPACE_ID>/<FILE_G>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 262
GET /dav/spaces/<SPACE_ID>/<FILE_H>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 263
GET /dav/spaces/<SPACE_ID>/<FILE_I>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 250
GET /dav/spaces/<SPACE_ID>/<FILE_J>.pdf?y=180&preview=1&scalingup=0&x=180&c=<HASH>&a=1 HTTP/2.0" 404 246
All within a ~2 second window. Domains, IPs, space IDs and filenames redacted.
Resulting CrowdSec decision:
| Source | Scope:Value | Reason | Action | Events | expiration |
| crowdsec | Ip:<REDACTED> | crowdsecurity/http-probing | ban | 11 | 167h59m |
Related
Additional note
The server returning 404 for unsupported types is documented behavior, so the server side is arguably correct here and this looks like a client-side issue. Worth flagging separately, though: returning 404 for "no preview available" makes ordinary browsing indistinguishable from path probing at the proxy layer, which is what turns a cosmetic gap into a lockout. A 204 or an explicit "not previewable" response would avoid that for every client at once.
Note: logs and reproduction steps are from my own instance. The write-up and
research were done with AI assistance.
Steps to reproduce
Expected behavior
The iOS app should filter by mime type before requesting thumbnails, the way the web client does, and should not issue duplicate preview requests for the same file within a single folder load.
Actual behavior
The iOS app requests
?preview=1for every file in the folder regardless of type. The thumbnails service cannot generate previews for PDF or DOCX, so each request returns HTTP 404 (documented behavior). Opening one folder of ~8 documents produces 12+ 404 responses within roughly 2 seconds.This is enough to trip intrusion detection watching the reverse proxy. In my case CrowdSec's
crowdsecurity/http-probingscenario fired on 11 events and issued a 7-day IP ban. Because the ban is enforced at the reverse proxy, it blocks every service behind that proxy, not just OpenCloud. Each subsequent app refresh re-triggers the ban immediately, so the app is effectively unusable from outside a whitelisted network.Differences observed between the two clients against the same folder and server:
Client
OpenCloud app version: 1.2.3Server configuration
OpenCloud version: 7.4.0
Deployment: Docker Compose, external reverse proxy (Traefik), external OIDC provider (Authelia), default POSIX storage driver.
Logs
OpenCloud server error log
Web client — one preview request, image only:
No preview requests were issued for the PDF/DOCX files in the same folder listing.
iOS app — one preview request per file, all types, with duplicates:
All within a ~2 second window. Domains, IPs, space IDs and filenames redacted.
Resulting CrowdSec decision:
Related
Additional note
The server returning 404 for unsupported types is documented behavior, so the server side is arguably correct here and this looks like a client-side issue. Worth flagging separately, though: returning 404 for "no preview available" makes ordinary browsing indistinguishable from path probing at the proxy layer, which is what turns a cosmetic gap into a lockout. A 204 or an explicit "not previewable" response would avoid that for every client at once.