认证
Frigate 在其数据库中存储用户信息。密码哈希使用行业标准 PBKDF2-SHA256 生成，迭代次数为 600,000 次。登录成功后，会生成一个带有过期日期的 JWT 令牌并设置为 cookie。Cookie 会根据需要自动刷新。这个 JWT 令牌也可以在 Authorization 头中作为 bearer 令牌传递。
用户可以在 UI 的设置 > 用户中进行管理。
以下端口可用于访问 Frigate Web UI。
| 端口 | 描述 |
|---|---|
8971 | 经过认证的 UI 和 API。反向代理应使用此端口。 |
5000 | 内部未经认证的 UI 和 API 访问。对此端口的访问应该受限。旨在用于 docker 网络内部，供与 Frigate 集成但不支持认证的服务使用。 |
初始设置
在启动时，会生成一个管理员用户和密码并打印在日志中。建议在首次登录后在设置 > 用户下为管理员账户设置新密码。
重置管理员密码
如果您被锁定在实例之外，您可以通过在配置文件中使用 reset_admin_password 设置来告诉 Frigate 在下次启动时重置管理员密码并将其打印在日志中。
auth:
reset_admin_password: true
登录失败速率限制
为了限制暴力攻击的风险，登录失败时可以使用速率限制。这是通过 SlowApi 实现的，有效值的字符串表示法可在文档中找到。
例如，当失败次数超过以下限制时，1/second;5/minute;20/hour 将限制登录端点：
- 每秒 1 次
- 每分钟 5 次
- 每小时 20 次
重启 Frigate 将重置速率限制。
如果您在代理后面运行 Frigate，您需要设置 trusted_proxies，否则这些速率限制将应用于上游代理 IP 地址。这意味着暴力攻击将限制来自其他设备的登录尝试，并可能暂时将您锁定在实例之外。为了确保速率限制仅应用于请求实际来源的 IP 地址，您需要列出要信任的上游网络。在查找请求源 IP 地址时，这些受信任的代理会与 X-Forwarded-For 头进行对比。
如果您在同一个 Docker Compose 文件中运行反向代理和 Frigate，以下是您的认证配置可能的样子：
auth:
failed_login_rate_limit: "1/second;5/minute;20/hour"
trusted_proxies:
- 172.18.0.0/16 # <---- 这是内部 Docker Compose 网络的子网
会话有效期
Frigate系统默认的用户认证会话有效期为24小时。该设置决定了用户认证会话在需要刷新令牌前保持活跃的时长——超过此时限后，用户必须重新登录才能继续使用系统。
虽然默认值在安全性和用户体验之间取得了平衡，但您可以根据具体的安全需求和使用偏好自定义这个时长。会话有效期以秒为单位进行配置。
默认值86400表示认证会话将在24小时后过期。其他配置示例：
0：将会话有效期设为0意味着用户每次访问应用时都需要 重新登录，或会在极短的立即超时后就需要重新认证604800：设置会话有效期为604800秒（7天）意味着用户只需在7天内刷新令牌即可保持登录状态
auth:
session_length: 86400
JWT 令牌密钥
JWT 令牌密钥需要保持安全。任何拥有此密钥的人都可以生成有效的 JWT 令牌来与 Frigate 进行认证。这应该是一个至少 64 个字符的加密随机字符串。
您可以使用 Python secret 库通过以下命令生成令牌：
python3 -c 'import secrets; print(secrets.token_hex(64))'
Frigate 按以下顺序查找 JWT 令牌密钥：
- 名为
FRIGATE_JWT_SECRET的环境变量 /run/secrets/中名为FRIGATE_JWT_SECRET的 docker 密钥- Home Assistant 插件选项中的
jwt_secret选项 - 配置目录中的
.jwt_secret文件
如果在启动时未找到密钥，Frigate 会生成一个并将其存储在配置目录中的 .jwt_secret 文件中。
更改密钥将使当前令牌失效。
代理 配置
Frigate 可以配置为利用常见上游认证代理（如 Authelia、Authentik、oauth2_proxy 或 traefik-forward-auth）的功能。
如果您正在使用上游代理的认证，您可能想要禁用 Frigate 的认证，因为 Frigate 数据库中的用户与通过代理认证的用户之间没有对应关系。另外，如果反向代理和 Frigate 之间的通信是通过不受信任的网络进行的，您应该在 proxy 配置中设置 auth_secret，并配置代理以将密钥值作为名为 X-Proxy-Secret 的头发送。假设这是一个不受信任的网络，您还需要配置真实的 TLS 证书以确保流量不会被简单地嗅探来窃取密钥。
以下是如何禁用 Frigate 的认证并确保请求仅来自您已知代理的示例。
auth:
enabled: False
proxy:
auth_secret: <一些随机的长字符串>
您可以使用以下代码生成随机密钥。
python3 -c 'import secrets; print(secrets.token_hex(64))'
Header映射
如果您已禁用 Frigate 的认证，并且您的代理支持传递带有已认证用户名和/或角色的头部，您可以使用 header_map 配置来指定头部名称，以便将其传递给 Frigate。例如，以下配置将映射 X-Forwarded-User 和 X-Forwarded-Role 值。头部名称不区分大小写。Header头中可以包含多个值，但必须使用英文逗号分隔。
proxy:
...
separator: "|" # 此默认值为逗号，但Authentik使用管道符作为分隔符
header_map:
user: x-forwarded-user
role: x-forwarded-role
Frigate 支持 admin 和 viewer 两种角色（见下文）。当使用端口 8971 时，Frigate 验证这些头部，后续请求使用 remote-user 和 remote-role 头部进行授权。
可以提供默认角色。映射的 role 头部中的任何值都将覆盖默认值。
proxy:
...
default_role: viewer
端口注意事项
认证端口 (8971)
- 完全支持头部映射。
remote-role头部决定用户的权限：- admin → 完全访问权限（用户管理、配置更改）。
- viewer → 只读访问权限。
- 确保您的代理同时发送用户和角色头部以正确执行角色控制。
未认证端口 (5000)
- 忽略头部用于角色控制。
- 所有请求都被视为匿名请求。
remote-role值被覆盖为管理员级别访问权限。- 此设计确保在受信任网络内的未认证内部使用。
注意，默认情况下只允许以下头部：
Remote-User
Remote-Groups
Remote-Email
Remote-Name
X-Forwarded-User
X-Forwarded-Groups
X-Forwarded-Email
X-Forwarded-Preferred-Username
X-authentik-username
X-authentik-groups
X-authentik-email
X-authentik-name
X-authentik-uid
如果您想添加更多选项，可以通过 docker bind mount 在 /usr/local/nginx/conf/proxy_trusted_headers.conf 覆盖默认文件。请参考源代码中的默认文件格式。
登录页面重定向
Frigate 优雅地执行登录页面重定向，应该可以与大多数认证代理配合使用。如果您的反向代理在 401、302 或 307 未授权响应时返回 Location 头部，Frigate 的前端将自动检测并重定向到该 URL。
自定义登出 URL
如果您的反向代理有专用的登出 URL，您可以使用 logout_url 配置选项指定。这将更新 UI 中"登出"链接的链接。
用户角色
Frigate 支持用户角色来控制对 UI 和 API 中某些功能的访问，例如管理用户或修改配置设置。角色可以在数据库中分配给用户或通过代理头部分配，并在通过认证端口（8971）访问 UI 或 API 时强制执行。
支持的角色
- admin：完全访问所有功能，包括用户管理和配置。
- viewer：对 UI 和 API 的只读访问，包括查看摄像头、核查和回放。UI 中的配置编辑器和设置不可访问。
角色强制执行
当使用认证端口（8971）时，通过 JWT 令牌或代理头部（如 remote-role）验证角色。
在内部未认证端口（5000）上，不强制执行角色。所有请求都被视为匿名，授予相当于管理员角色的访问权限，没有限制。
要使用基于角色的访 问控制，您必须直接或通过反向代理通过**认证端口（8971）**连接到 Frigate。
UI 中的角色可见性
- 通过端口
8971登录时，您的用户名和角色显示在账户菜单（底角）中。 - 使用端口
5000时，UI 将始终显示用户名为"anonymous"，角色为"admin"。
管理用户角色
- 通过端口
8971以管理员用户身份登录。 - 导航到设置 > 用户。
- 通过选择admin或viewer编辑用户的角色。