Celium 账号与注册

Celium 不把身份外包给任何人：没有 OAuth、没有第三方目录服务，登录不需要任何外部 服务可达。一个账号就是本服务器状态文件里的一行：用户名、密码哈希，以及它拥有的 机器。这是产品决定，不是实现细节——一个"自托管"的网络，如果登录依赖别人的服务， 那它就不是自托管的。

数据模型

Account --拥有--> User --拥有--> Node
   |                |
   |                +-- ACL 规则写的就是它（group: / login name）
   +-- 登录、签发节点密钥、邀请他人

User 这层间接是有意的：节点归属、节点记录、ACL 组都是围绕"tailnet 用户"设计的， 而账号是"登录方式"。把两者分开，意味着改密码或停用登录不会让已经注册的机器失去 归属——那台机器仍然是同一个用户的资产。

账号还可以邀请其他人：第一个账号通过引导（bootstrap）产生，此后的每个账号都 是因为已有用户为它背书才出现的。邀请码默认一次性，可设置次数与有效期。

HTTP API

所有接口都是普通 JSON over HTTP，浏览器、CLI、手机客户端用同一套。认证是 Authorization: Bearer <session token>——不用 cookie，因此没有 CSRF 面。

公开（无需凭据）

/api/server-info 是客户端第一次接触服务器时唯一需要的东西：它让"首次连接"不必 手工拷贝控制公钥，同时不泄露任何非公开信息（这些值本来就会打印在服务器启动日志 和首页上）。

需要登录

需要管理员

管理员还可以继续使用既有的 /admin/api/（bearer admin token），以及 /admin 控制台：

后一条是刻意分开的：邀请码是一扇门，而一位已经离职的同事留下的未使用邀请码，正是 需要被找出来并撤销的东西——只让创建者看见，就等于看不见。

控制台（/admin）已经把账号与邀请纳入管理：停用/启用、授予/撤销管理员、重置密码、 查看全部邀请码。这三类动作都不需要管理员本人拥有账号，只需要部署自己的 admin token——这正是"唯一账号的密码丢了"那天需要的路径。

用浏览器把机器接入

上面那条路径要求你在那台机器上拥有账号：要么先登录，要么让管理员签发节点密钥。 一台没有人坐在面前的服务器（机架里的机器、CI 里的容器、刚开的 VPS）两样都没有，而账号 的主人在别处、面前正好有一个浏览器。设备授权流程（RFC 8628 的形状）就是为这种情况存在 的，celium up 在发现本机没有会话时自动走这条路：

$ celium up --control-url=https://control.example.com --trust-server-info
celium: this machine is not logged in. Approve it in a browser:

  https://login.celium.cn/a/7k4m-p2qr

  Open that URL and sign in to your Celium account; the page shows which
  machine it is about and asks you to approve or deny it.

  Check that the page describes *this* machine:
    hostname     web-01
    fingerprint  3f9a2c4d1b70
    machine key  mkey:...

命令行在这里只做两件事：POST /api/device/start 拿到一个码，然后轮询 POST /api/device/poll。两次调用都不带任何凭据——这正是要点：这台机器上不需要、 也不会留下任何账号凭据。人在浏览器里打开 /a/<code>（由本服务器渲染，因为账号就在 这里），页面显示机器的主机名、平台、机器密钥与它自己报的来源地址，要求输入账号密码， 然后给出 Approve / Deny 两个按钮。批准时服务器签发一把一次性、预授权的节点密钥， 归批准者所有；客户端在下一次轮询里拿到它，交给守护进程注册——与 --auth-key 走的是 同一条路，注册流程一行没改。

审批 URL 的来源由 Config.LoginURL 决定（celium-control --login-url=https://login.celium.cn）。 不配置时取发起请求的 Host 与协议，这是服务器唯一能确定"自己确实在这个地址上提供服务" 的取值；放在反向代理后面、或对外名字与节点拨号名字不一致时，才需要显式配置。客户端不会 硬编码任何主机名，只打印服务器返回的那个 URL。

一条命令把机器接入

# 1. 注册（第一个账号自动成为管理员）
curl -sX POST https://control.example.com/api/register \
  -H 'Content-Type: application/json' \
  -d '{"username":"alice","password":"correct-horse-1"}'
# → {"token":"...","account":{...},"isFirstUser":true}

# 2. 签发这台机器的入网密钥
curl -sX POST https://control.example.com/api/node-keys \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"description":"alice laptop","preauthorized":true}'
# → {"Value":"celiumkey-...","...":...}

# 3. 用这个密钥把节点拉起来
celium up --control-url=https://control.example.com \
          --control-key=controlkey:... \
          --auth-key=celiumkey-...

邀请别人：

curl -sX POST https://control.example.com/api/invites \
  -H "Authorization: Bearer $TOKEN" -d '{"note":"for bob"}'
# → {"code":"abcd-efgh-..."}  交给对方，让他注册时带上 invite 字段

安全上的具体选择

与 ACL 的关系

账号不直接出现在 ACL 里，它对应的 User 才是：group:dev = ["alice@example.com"] 这样的规则在编译时展开为该用户拥有的所有节点的虚拟地址。因此"停用账号"不会影响 已经写好的策略，而"删除账号"会让策略里引用的那个身份不再匹配任何机器。