v2.1.0-beta.1
Pre-release
Pre-release
·
7 commits
to main
since this release
Security
- Tool calls now execute as the token's owner, not a substituted admin.
Previously every WebSocket-backed call ran as the first active admin
(admins[0]), so any valid bearer token gained admin rights. Calls now run
as the Home Assistant user who owns the token, and HA's own permission
machinery enforces that user's rights. Mutating operations fail closed
when no authenticated user is present.ha_authnow acts on the calling
token's own user (it too previously usedadmins[0], letting any token mint
an admin long-lived token). - Admin-only operations now require an admin token. Tools that mutate via
direct HA APIs with no per-user check of their own —ha_registry,
ha_config_entries,ha_config_flow,ha_energy,ha_statistics,
ha_set_state,ha_delete_state— now require the token's user to be an
administrator (matching Home Assistant's own policy for those operations).
Their read ops remain available to any token. ha_blueprint op=importnow rejectsfilenamevalues containing path
separators or non-.yamlextensions, closing a path-traversal vector.- Destructive/write ops are now gated per
op. Several meta-tools
(ha_registry,ha_config_entries,ha_blueprint,ha_energy,
ha_statistics,ha_helper,ha_backup,ha_yaml_config) previously
declared their gating only in prose or a coarse whole-tool flag, so
create/update/delete/purge/restore could run withallow_destructive(or
evenallow_write) disabled. Gating is now declarative and enforced
centrally before the handler runs.
Changed
- Destructive ops (
delete/remove/purge/revoke/restore/
clear) now requireallow_destructive(default off) rather than
running underallow_write. Workflows that relied on the old behavior must
enable the toggle. - Meta-tool permission gating moved from whole-tool
requires_*flags to
declarative per-opwrite_ops/destructive_ops. This also fixes
over-gating:ha_recorder op=infoandha_hacsread ops no longer
require a write/destructive toggle and reappear in the default tool list.