Image Security Settings
The Image Security tab sets the protection defaults that new galleries start with: the protection level, DevTools detection and canvas rendering.
This page is the reference for what each protection level actually does. See Photo Protection for the overview and the caveats (no protection stops a determined visitor from capturing the screen).
All of them are creation defaults. A new gallery copies them when it is created; changing them later does not touch existing galleries. DevTools detection and canvas rendering can be changed per gallery afterwards (event page → Settings → Downloads); the protection level cannot be changed in the admin UI after creation — only through the admin API (PUT /api/admin/events/:id accepts protection_level).
Default protection level
| Setting | Default | What it does |
|---|---|---|
| Default protection level | standard | Copied into every new gallery. An explicit protection_level in the create request (admin API or v1 API) wins over it. |
What each level does in the current gallery code:
| Level | DevTools detection | Lightbox rendering | Full-resolution zoom | Full-size view served |
|---|---|---|---|---|
basic | per-gallery switch | <img> (canvas only if the gallery’s canvas switch is on) | allowed (when downloads hand out the original) | original / preview |
standard | per-gallery switch | as basic | as basic | original / preview |
enhanced | always on | as basic, plus a faint overlay pattern while the lightbox is open | refused | original / preview |
maximum | always on, high sensitivity: the gallery page navigates away and the lightbox closes on detection | always canvas | refused | capped copy: fits inside 1920 × 1080, quality 60, no EXIF |
basic and standard currently behave the same. The right-click block is not tied to the level at all: it is the gallery’s own Block right-click menu switch (on by default).
Maximum: capped full-size view
Available on the beta channel from v3.175.0-beta.0. At maximum, the gallery photo route (/api/gallery/:slug/photo/:photoId) and the preview route (/api/gallery/:slug/preview/:photoId, including its ?w= sizes) no longer send the original or the full preview. They answer a copy cut from the stored preview per request:
- fits inside 1920 × 1080, never upscaled, re-encoded at quality 60
- rotation applied, no EXIF or GPS data
- a watermark, if configured, is applied before the downscale
- a WebP preview (transparency or animation) stays WebP; everything else is JPEG
- it runs in the isolated image worker pool and answers
503withRetry-Afterwhen the workers are busy, instead of queueing or falling back to the original - if no preview can be made (for example a corrupt source), the route answers
404
The admin preview of a gallery is capped the same way, so it shows what guests see. Not capped: standard and enhanced, videos, and the download routes — a guest who may download still receives the file the download settings allow. Turn downloads off or limit their resolution if the cap is meant to be the only size a guest can get.
The label of the maximum option in the picker mentions the cap in English and German; the other languages still show the older label.
On the stable channel (v3.134.x) maximum has no server-side cap: the full-size view serves the same file as standard. Enhanced and maximum are client-side rendering modes only there (from v3.134.7 they serve the normal photo route instead of a broken token link).
Image quality
| Setting | Default | What it does |
|---|---|---|
default_image_quality | 85 | Value from 1–100, copied into a new gallery’s image_quality field. |
The value is stored on the gallery and returned with its settings, but no rendition is encoded with it. Older versions show it as Default image quality in this tab; newer releases drop the input because it has no effect, and keep the stored value and the API field. Thumbnail and preview quality come from Thumbnails; the maximum cap always uses quality 60.
DevTools detection
| Setting | Default | What it does |
|---|---|---|
| Enable DevTools detection by default | on | New galleries start with Detect developer tools switched on. At enhanced and maximum detection runs regardless of the switch. |
Canvas rendering
| Setting | Default | What it does |
|---|---|---|
| Enable canvas rendering in the lightbox by default | off | New galleries start with Canvas rendering in the lightbox switched on. The lightbox then draws the photo into a <canvas> instead of an <img>, which defeats drag-to-save and “Save image as”. |
At maximum the lightbox always uses canvas rendering. Canvas rendering, like enhanced and maximum, also switches off full-resolution zoom in the lightbox.
Removed settings
Builds before v3.175.0-beta.0 showed Rate Limiting (image requests per minute / 5 minutes / hour) and Security Monitoring cards (suspicious-activity threshold, auto-block, block suspicious IPs, monitoring and DB logging switches) on this tab. None of them were enforced: the middleware that read the budgets was no longer mounted on any route, and nothing read the monitoring switches. Both cards are gone, POST /api/admin/image-security/block-ip answers 404, and the RATE_LIMIT_NETWORK_MULTIPLIER variable is no longer read. Fragmentation (splitting a photo into tiles) no longer exists either.
The stable channel (v3.134.x) still shows these cards, but they have no effect there either.
For limits that are enforced, see API rate limiting on the Security tab.
Where it’s enforced
- Creation defaults:
backend/src/services/eventSettings.js(getImageSecurityDefaults) maximumcap:backend/src/services/galleryAssetPolicy.js(MAXIMUM_PROTECTION_CAP) and the gallery media routes- DevTools detection and canvas rendering: the gallery frontend (
GalleryView,PhotoLightbox)