Store and read avatars under one domain-independent prefix

FixSecurityService
Shipped
July 31, 2026 at 8:13 PM UTC
Author
Kamo
Commit
7103dae

Avatar object paths were prefixed with the domain of whatever host the request arrived on (getPublicBucketName → kamocrm-com, optionone-com, cluster-local, …), and the prefix was recomputed on every read. An avatar hangs off User, and a user can be a member of several organizations, so a photo uploaded while on one organization's domain resolved to a path that does not exist when read from another — MinIO returned NoSuchKey and the image 404'd. Most of the UI hides that behind an initials fallback; email signatures render a bare <img>, so the member photo simply vanished while the company logo (a per-domain theme asset resolved client-side) kept loading. All avatar object paths now come from AvatarObjectPaths, which uses one fixed "platform" prefix. Bucket and folder layout are unchanged, and the existing 83 objects were copied — not moved — into the new prefix, so any URL already in the wild still resolves.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing