🎯 Feature Description
Shelly Manager has no authentication of its own protecting the Web UI or API - anyone who can reach the host/hostname can use it fully, with no login or token required. I'd like an optional built-in auth layer (e.g. a single admin password or API token) that gates access to both.
🤔 Problem Statement
I run Shelly Manager self-hosted on my home LAN (API and Web UI as separate containers, each behind its own reverse-proxy hostname, no cloud). I'm in the process of password-protecting my individual Shelly devices, but Shelly Manager itself has no login of any kind - it holds the stored device credentials and uses them on my behalf, so anyone on the network can reach it and get full control (scan, status, actions, firmware updates, backups) without ever needing a device's own password. This effectively defeats the point of protecting the devices individually, since the manager becomes the unprotected shortcut around that.
💡 Proposed Solution
An optional admin credential (password or API token) required to use both the API and the Web UI, off by default to preserve the zero-configuration philosophy - enabled via an env var, similar in spirit to how SHELLY_SECRET_KEY is already configured. Since the API and Web UI are commonly deployed on separate origins/hostnames behind a reverse proxy, a token-based scheme (sent explicitly by the Web UI's own API client) would compose better than a cookie/session approach, which doesn't cross origins without extra reverse-proxy plumbing.
🔄 Alternatives Considered
Putting HTTP Basic Auth or an auth proxy (Authelia/oauth2-proxy) in front via the reverse proxy works for the Web UI's own page load, but not for the API when it's on a separate hostname: the Web UI's Axios client doesn't set withCredentials, so the browser won't forward cookies or cached Basic Auth cross-origin to a separate API hostname - the reverse proxy would 401 every API call and break the UI. Making both origins share a hostname (path-based routing) avoids that, but isn't how everyone deploys the two containers. Native app-level auth would sidestep this whole class of problem regardless of deployment topology.
📱 Applicable Device Types
All Shelly devices
🏗️ Feature Area
Security & Authentication
⭐ Priority Level
Important for my use case
⚙️ Technical Considerations
Should stay fully optional/off by default given the project's zero-configuration design. A shared-secret/token model (checked via a header, similar to how SHELLY_SECRET_KEY-derived encryption already works) would avoid CORS/cross-origin credential issues that a cookie-based session would run into when the API and Web UI sit behind different hostnames.
🔍 Duplicate Check
🤝 Contribution
🎯 Feature Description
Shelly Manager has no authentication of its own protecting the Web UI or API - anyone who can reach the host/hostname can use it fully, with no login or token required. I'd like an optional built-in auth layer (e.g. a single admin password or API token) that gates access to both.
🤔 Problem Statement
I run Shelly Manager self-hosted on my home LAN (API and Web UI as separate containers, each behind its own reverse-proxy hostname, no cloud). I'm in the process of password-protecting my individual Shelly devices, but Shelly Manager itself has no login of any kind - it holds the stored device credentials and uses them on my behalf, so anyone on the network can reach it and get full control (scan, status, actions, firmware updates, backups) without ever needing a device's own password. This effectively defeats the point of protecting the devices individually, since the manager becomes the unprotected shortcut around that.
💡 Proposed Solution
An optional admin credential (password or API token) required to use both the API and the Web UI, off by default to preserve the zero-configuration philosophy - enabled via an env var, similar in spirit to how SHELLY_SECRET_KEY is already configured. Since the API and Web UI are commonly deployed on separate origins/hostnames behind a reverse proxy, a token-based scheme (sent explicitly by the Web UI's own API client) would compose better than a cookie/session approach, which doesn't cross origins without extra reverse-proxy plumbing.
🔄 Alternatives Considered
Putting HTTP Basic Auth or an auth proxy (Authelia/oauth2-proxy) in front via the reverse proxy works for the Web UI's own page load, but not for the API when it's on a separate hostname: the Web UI's Axios client doesn't set withCredentials, so the browser won't forward cookies or cached Basic Auth cross-origin to a separate API hostname - the reverse proxy would 401 every API call and break the UI. Making both origins share a hostname (path-based routing) avoids that, but isn't how everyone deploys the two containers. Native app-level auth would sidestep this whole class of problem regardless of deployment topology.
📱 Applicable Device Types
All Shelly devices
🏗️ Feature Area
Security & Authentication
⭐ Priority Level
Important for my use case
⚙️ Technical Considerations
Should stay fully optional/off by default given the project's zero-configuration design. A shared-secret/token model (checked via a header, similar to how SHELLY_SECRET_KEY-derived encryption already works) would avoid CORS/cross-origin credential issues that a cookie-based session would run into when the API and Web UI sit behind different hostnames.
🔍 Duplicate Check
🤝 Contribution