#1108 — Long-lived camera-stream tokens for HA / Frigate / kiosks. Camera-only
V1, hard 365-day cap (no infinite tokens), pbkdf2 hashed at rest, plaintext
shown to user exactly once on creation. New "Camera API Tokens" panel under
Settings → API Keys with self-service create/revoke, styled confirm modal,
admin "All users" view for leak triage. Auth path: /camera/stream tries the
existing 60-min ephemeral table first, falls through to the long-lived path.
Indexed lookup_prefix keeps verify O(1) per token.
Permission audit: gated the existing API-keys-CRUD + Webhook docs + API
Browser content behind api_keys:read so non-admins with camera:view land on
the API Keys tab and see only the Camera Tokens panel they actually have
permission to use. Grid layout collapses to single column for non-admins.
Tests: 29 new backend (15 service + 14 integration covering create/list/
revoke ownership rules, the auth fall-through, scope enforcement, prefix
collisions) + 6 new frontend tests for the section UI including the new
modal flow. All 77 backend tests + 21 frontend camera tests pass. Ruff
clean (lint + format).
Docs: README updated with fan-out + long-lived-token bullets. Wiki gets a
new "Long-Lived Camera Tokens" section under features/camera.md (HA YAML
example, security model, permission requirements, revoke flow). Website
features.html gets the bullet under Camera Streaming.
Also includes #1089 follow-up tweaks already merged in this branch:
_stream_start_times.setdefault for accurate stream_uptime, subscribe()
RuntimeError retry to close the grace-vs-subscribe race, atomic
unsubscribe count via the iter_subscriber on_unsubscribe callback.
The SetupRequest Pydantic schema enforced password complexity unconditionally,
but the route ignores admin_password entirely when an admin user already
exists (the common case for re-enabling auth after it was disabled, or for
LDAP deployments where the local admin is a placeholder). A legitimate
existing password that predated the complexity rule — or the placeholder the
form sends in LDAP mode — hit the Pydantic validator before the route body
could decide it wasn't needed, surfacing as:
422 Value error, Password must contain at least one special character
Move the complexity check out of the schema and into the route body, scoped
to the branch that actually creates a new local admin. Re-enabling auth with
an existing admin now accepts whatever is in the field; first-time setup
still rejects weak passwords with a clear 400 including the specific rule
that was violated.
Regression coverage in test_auth_api.py::TestAuthSetupAPI:
- test_setup_weak_password_rejected_when_creating_new_admin — fresh setup
with "NoSpecial1" → 400, "special character" in detail
- test_setup_reenable_with_existing_admin_ignores_password — seeds an admin,
POSTs /setup with a complexity-failing password → 200, admin_created=false
Two related LDAP authentication changes.
Fix: POSIX primary group membership was ignored. authenticate_ldap_user
only searched for posixGroup entries via memberUid (supplementary
groups). A user's primary group — referenced by the gidNumber attribute
on the user object matching gidNumber on a posixGroup — was never
resolved, so users whose role came from their primary group landed
without the expected permissions. The authenticator now runs a second
search for posixGroup entries whose gidNumber matches the user's
primary gidNumber, then dedupes DNs case-insensitively before passing
the list to resolve_group_mapping (LDAP DNs are case-insensitive by
spec).
New feature: ldap_default_group setting. Settings → Authentication →
LDAP → Advanced has a new "Default group" selector. When an LDAP user
authenticates but is not listed in any mapped LDAP group, they are
assigned to this fallback group instead of being left with no groups
(and therefore no permissions). A warning is logged each time the
fallback is applied so admins can spot missing group assignments.
Empty setting preserves the old behavior.
Tests: added 4 mocked authenticate_ldap_user tests covering primary
gidNumber lookup, dedupe of overlapping memberUid+primary gid matches,
case-insensitive DN dedupe, and the guard when a user entry has no
gidNumber attribute. Also extended the existing parse_ldap_config tests
to cover the new default_group field.
Backend: ldap_service.py (primary group + dedupe + default_group
field), schemas/settings.py (schema field), api/routes/auth.py
(fallback wiring in _provision_ldap_user / _sync_ldap_user).
Frontend: LDAPSettings.tsx default-group dropdown in the Advanced
collapsible, api/client.ts type field, new i18n keys in all 7 locales
(defaultGroup, defaultGroupNone, defaultGroupHint).
Users can authenticate against an LDAP/AD server with configurable
server URL, bind DN, search base, and user filter. Supports StartTLS
and LDAPS — plaintext is not allowed. Both Active Directory (memberOf)
and POSIX groups (memberUid) are mapped to BamBuddy groups on each
login. Auto-provisioning creates local accounts on first LDAP login.
Local admin accounts remain as fallback when LDAP is unreachable.
Password management is disabled for LDAP users.
Bambuddy can now use an external PostgreSQL database via the
DATABASE_URL environment variable. SQLite remains the default.
Dialect-aware helpers handle upserts, PRAGMAs, FTS (FTS5 vs
tsvector+GIN), backup/restore, and health checks. All migration
blocks use savepoints to prevent Postgres transaction poisoning.
Backups are always portable SQLite format regardless of backend.
Cross-database restore imports SQLite backups into PostgreSQL
with automatic boolean/datetime conversion, NOT NULL default
filling, and FK constraint handling.
- Sanitize project notes with DOMPurify before rendering via
dangerouslySetInnerHTML (ProjectDetailPage.tsx)
- Replace hand-rolled HTML sanitizer with DOMPurify in ProjectPageModal
to prevent attribute injection via crafted 3MF href values
- Block /api/v1/auth/setup when auth is already enabled to prevent
unauthenticated clients from disabling authentication remotely
When Bambuddy auth is enabled, the SpoolBuddy kiosk gets redirected to
the login page because ProtectedRoute requires a user from GET /auth/me,
which only handled JWT tokens. The kiosk daemon already has an API key
but couldn't use it to satisfy the frontend auth check.
- Backend: /auth/me now accepts API keys (Bearer bb_xxx or X-API-Key)
and returns a synthetic admin UserResponse with all permissions
- Frontend: AuthContext reads ?token= from URL on first load, stores in
localStorage, and strips from URL (prevents history/referrer leakage)
- Install script: kiosk URL now includes ?token=${API_KEY}
- Tests: 3 new integration tests (Bearer API key, X-API-Key header,
invalid key rejection)
SMTP settings endpoints (GET/POST /auth/smtp, POST /auth/smtp/test)
used Depends(get_current_active_user) which always requires a logged-in
user. Replaced with RequirePermissionIfAuthEnabled to match the pattern
used by all other settings endpoints — accessible when auth is disabled,
permission-gated when auth is enabled.
Simplify always-true authEnabled ternary and localSettings truthiness
checks in SettingsPage.tsx. Remove commented-out auth re-setup guard
and its dead _existing_setting/_user_count queries from auth.py.
Add clarifying comments to firmware_check.py api_key logs (model
identifier, not a secret).
Implement a full permissions system replacing simple admin/user roles:
Backend:
- Add Group model with many-to-many user relationship
- Add 50+ granular permissions (resource:action pattern)
- Create default groups: Administrators, Operators, Viewers
- Add permission-checking dependencies for route protection
- Add groups API endpoints (CRUD, user assignment)
- Add change password endpoint for users
- Update backup/restore to include groups
- Migrate existing users to groups on startup
Frontend:
- Add GroupsPage for managing groups and permissions
- Add permission helpers to AuthContext (hasPermission, hasAnyPermission)
- Add PermissionRoute component for protected routes
- Disable buttons/features based on permissions (with tooltips)
- Add change password modal in sidebar for all users
- Add forgot password info modal on login page
- Show user groups in UsersPage with group assignment
Testing:
- Add integration tests for groups API
- Add tests for user-group assignments
- Add tests for change password endpoint
- Seed default groups in test fixtures
Closes#28#161
Home Assistant smart plugs can now use separate sensor entities for
energy monitoring, enabling energy tracking for plugs that expose
power/energy data as separate sensors (Tapo, IKEA Zigbee2mqtt, etc.).
Features:
- Configure dedicated power (W), today (kWh), and total (kWh) sensors
- New API endpoint GET /api/v1/smart-plugs/ha/sensors lists available sensors
- Falls back to switch entity attributes if no sensors configured
- Print energy tracking now works for HA plugs (not just Tasmota)
Backend:
- Added ha_power_entity, ha_energy_today_entity, ha_energy_total_entity
fields to SmartPlug model
- Updated get_energy() to fetch from configured sensor entities
- Added _get_plug_energy() helper to handle both plug types
- Updated backup/restore to include new fields
- Added database migration for new columns
Frontend:
- Added energy sensor dropdowns in AddSmartPlugModal (shown for HA plugs)
- Dropdowns filtered by unit (W/kW for power, kWh/Wh for energy)
Tests:
- Added 4 new integration tests for HA energy sensor functionality
Docs:
- Updated README with new feature
- Updated CHANGELOG with 0.1.6b11 entry
Fixes:
- Fixed is_auth_enabled() returning None instead of False when setting doesn't exist (in both auth.py and routes/auth.py)
- Fixed get_current_user() crashing when credentials is None
- Added missing async_session patch in conftest.py for auth tests
Backup/Restore - Added Users Support
- Added include_users parameter to backup export
- Users are exported with username, role, and is_active (passwords excluded for security)
- Restore creates users with temporary passwords that must be changed
Backend Tests - 16 New Auth Tests
- test_auth_api.py with tests for:
- Auth status endpoint
- Auth setup (enable/disable)
- Login flow (success, invalid credentials, auth disabled)
- /me endpoint with/without token
- User management (list, create, update, delete)
- Auth disable
Frontend Tests - 6 New Login Tests
- LoginPage.test.tsx with tests for:
- Form rendering
- Input validation
- Login submission
- Loading states
Documentation Updates
- CHANGELOG.md/README.md: Added authentication feature description
- Website (features.html): Added new "Optional Authentication" section
- Wiki: Created authentication.md with full documentation
- Wiki index: Added authentication to features list
maziggy