GongBU安全机制全解析：JWT认证、bcrypt密码哈希与注册令牌策略，公网部署如何更安心

GongBU 是一个免代码的大模型（LLM）微调平台，源自 CIKM 2024 论文。很多用户部署后的第一个疑问是：这台机器上的平台能不能安全地开放给更多人、甚至暴露到公网？本文面向新手，完整解析 GongBU 的四大安全机制——JWT 认证、bcrypt 密码哈希、注册令牌策略与数据可见性控制，并附上一份可直接照做的公网部署加固清单，帮你更安心地使用这台 AI 训练平台。

GongBU 的定位是"无代码微调平台"：只要有浏览器，就能上传领域数据、完成模型的微调、评测与部署，全程不需要写一行代码。而一旦这样的平台被多人共用，"谁能登录、密码怎么存、数据谁能看"就成了安全的核心问题。

GongBU 安全体系速览：三道关卡 + 一道数据隔离

先看整体架构，GongBU 的安全防线可以分为四层：

下面逐一拆解它们的工作原理。

安全机制一：JWT 认证——登录一次，凭令牌通行

🔐登录流程：用户在前端登录页输入用户名和密码后，前端会调用后端的/token接口（见 backend/backend/main.py）。密码校验通过后，服务器签发一个 JWT（JSON Web Token）返回给浏览器。

这个令牌是怎么生成的？核心逻辑在 backend/backend/auth.py 中：

• 采用HS256对称签名算法，签名密钥来自环境变量SERCET_KEY（auth.py 第8行）；
• 令牌里携带用户标识（sub）和过期时间exp；
• 有效期由TOKEN_EXPIRATION_DELTA控制，默认为1 天——也就是说令牌过期后需要重新登录，减少了令牌被盗后的有效窗口。

后续请求如何鉴权？前端登录后把令牌存入浏览器localStorage（见 frontend/src/routes/Login.svelte），之后每次请求都会自动带上Authorization: Bearer <token>请求头。后端通过get_current_identifier函数解析并校验令牌（auth.py 第29-37行），令牌无效或过期一律返回401 Invalid token，请求直接被拒绝。

💡 一个贴心的细节：登录失败时后端统一返回 "Incorrect username or password"，不会区分"用户不存在"还是"密码错误"。这是防止攻击者通过报错信息逐个试探用户名的经典做法。

此外，页面刷新时前端会调用/user/me接口验证令牌是否仍有效（见 frontend/src/routes/+layout.svelte），令牌失效则自动清除并回到登录页。

安全机制二：bcrypt 密码哈希——明文密码不落库

🔒 无论什么系统，"密码必须以哈希形式存储"都是底线，GongBU 在这点上没有含糊：

• 注册时：密码先经过bcrypt.hash()加盐哈希后才写入数据库（backend/backend/routers/user.py 第31行），数据库中存的只是一串形如$2b$...的哈希值；
• 登录时：用bcrypt.checkpw()比对用户输入的明文与库中哈希是否匹配（backend/backend/main.py 第43行）；
• 哈希上下文统一使用 bcrypt 算法（auth.py 第11行 的CryptContext）。

bcrypt 的两大特点是自带盐值和计算缓慢：每个密码即使内容相同，生成的哈希也完全不同；同时它故意消耗 CPU 时间，让暴力破解字典的成本极高。即使数据库文件不幸泄露，攻击者拿到的也是一堆无法直接还原的哈希串，而不是明文密码。

安全机制三：注册令牌策略——第一道门就锁好

GongBU 默认不提供任何初始用户，第一个注册的人就是管理员。为了防止任何访问到页面的人随意开户，平台设计了**注册令牌（sign_up_token）**机制：

1. 自动颁发：后端启动时会生成一个一次性令牌——基于时间戳 + 16 字节随机数的 MD5 摘要（auth.py 第46-53行），写入sign_up_token/sign_up_token.txt文件；
2. 宿主机可见：通过 Docker 卷挂载，该文件会出现在部署目录的sign_up_token/下（docker-compose.prod.yaml 第32行），只有能接触服务器的管理员才拿得到；
3. 前端动态感知：注册页加载时会查询/user/signup-token-required接口，决定是否展示"注册验证 Token"输入框（frontend/src/routes/Signup.svelte）；
4. 严格比对：注册时服务器会与本地令牌文件比对，不一致直接返回invalid_sign_up_token（user.py 第15-34行）。

管理员拿到令牌后，通过聊天工具私下发给可信用户即可完成授权式开户；令牌文件内容也可以随时替换为自定义值。需要注册时，前端页面会展示类似下方的表单（含"注册验证 Token"字段）。

⚠️ 两个实操要点：

• 后端每次启动都会重新生成令牌，重启服务后请让用户使用最新的令牌值；
• 官方 README 说明可通过设置环境变量NO_SIGNUP_TOKEN切换更宽松的注册策略（允许任何人注册），适合内部局域网快速演示；公网环境则建议坚持令牌策略。详见 README.md 的 Usage 与 Security Issues 章节。

附赠机制：数据可见性控制——owner 与 public 双字段

光有登录还不够，平台里的数据集、模型池等资源还需要按人隔离。GongBU 给每类资源（Dataset、OpenLLM、Adapter、Pool）都设计了owner（属主）和public（是否公开）两个字段：

• 查询时统一走accessible过滤：只有"资源属于我"或"资源被设为公开"才可见（auth.py 第73-75行）；
• 只有属主本人才能切换公开开关，非属主调用会收到not_owner拒绝（backend/backend/routers/visibility.py 第72-86行）。

这意味着多位同事共用一台 GongBU 时，你的私有数据集不会出现在别人的下拉列表里，想共享时再一键设为 public 即可——多用户协作与数据隔离兼得。

公网部署加固清单：5 步让 GongBU 更安心

GongBU 官方在 README 中明确说明：平台在客户端与服务端之间使用明文传输数据，若部署在开放网络，需要自行启用 SSL 并保护数据库（生产模式下所有请求都经过 nginx 反向代理，改配置即可）。结合源码，我们整理出这份 5 步加固清单：

1. 更换SERCET_KEY🔑 这是 JWT 的签名密钥，docker-compose.prod.yaml 第39行 默认值为secret。密钥一旦泄露，任何人都能伪造任意用户的合法令牌！请务必改成一串足够长的随机字符串，这是公网部署的第一优先级。

2. 加固数据库访问🗄️ Postgres 默认密码为pwd，且 docker-compose.prod.yaml 第17行 把 54320 端口映射到了宿主机。公网部署时：修改POSTGRES_PASSWORD，并删除或收紧该端口映射——数据库不需要被外部直接访问。

3. 启用 HTTPS🌐 生产模式下 nginx 反向代理（proxy/nginx.prod.conf）统一承接所有请求：/api/转发到后端、静态资源走前端。只需在 nginx 配置中加上 443 端口与证书配置，登录密码和令牌全程加密传输。

4. 管好注册令牌🎫 令牌只通过可信渠道私下分发；重启后端后记得同步最新令牌；团队规模小且信任度高时也可用它做"邀请制"开户。

5. 善用 public 开关🔍 默认资源私有，只把确需共享的数据集、模型显式设为公开，从数据层面减少暴露面。

常见问题 FAQ

Q1：重启服务器后，之前发给用户的注册令牌失效了怎么办？

后端每次启动都会重新生成令牌并覆盖sign_up_token/sign_up_token.txt，重新读取该文件最新内容分发给用户即可。

Q2：JWT 令牌有效期是多久？

默认 1 天（TOKEN_EXPIRATION_DELTA = 1，见 auth.py 第9行）。过期后所有 API 返回 401，浏览器端会自动清除令牌并跳回登录页，重新登录即可。

Q3：GongBU 可以直接裸奔在公网上吗？

不建议直接裸奔。平台本身提供了 JWT 认证、bcrypt 哈希、注册令牌和可见性隔离，但传输层加密（HTTPS）和数据库防护需要你按上面的清单手动补齐——补齐后即可安心多用户使用。

小结

GongBU 把"免代码"的易用性与"多层防御"的安全性结合在了一起：JWT 认证守住 API 大门，bcrypt确保密码泄露风险可控，注册令牌把开户权握在管理员手里，owner/public 可见性让多人协作时数据各归其主。只要记住三件事——换掉SERCET_KEY、给 nginx 挂上 HTTPS、管好注册令牌与数据库密码，这台大模型微调平台在公网环境下也能稳稳运行。