Hodor：用最简单的方式给 Web 应用加上登录

做完一个内部工具、监控面板或者测试环境后，你总得加个登录吧？可一想到要搞用户表、密码加密、OAuth、Session 管理，就觉得麻烦。明明只是想挡一下外人，却要拉进一堆认证框架。

Hodor 就是为了解决这个问题。它把“复杂”两个字扔掉，只留一个最简单的做法：用一个共享密码就把整个应用挡住。

简单到只剩一个密码

Hodor 不管用户、不管数据库、不管第三方登录。它只有一个二进制文件，你给它设个密码，部署在应用前面就完事了。访问的人只要输对密码，就能看到后面的内容。

这种方式当然不适合要做成公开 SaaS 的产品。但对内部仪表盘、预发布环境、原型演示，或者小团队共享的工具来说，它反而更实用。

它到底省掉了什么

Hodor 的优雅之处在于它“没有”哪些东西：

• 没有用户数据库
• 没有 OAuth 跳转
• 没有复杂的 Session 管理
• 只有一个编译好的二进制文件

你只要把它当成反向代理放在应用前面，配好密码，马上就能用。不用再为每个应用单独写认证中间件。

适合用在哪些场景

• 内部监控面板：运维团队想看指标和日志，但不想维护一堆账号
• 测试环境：快速给预发布站点加一层保护
• 原型演示：给客户或投资人看东西时，不想花时间做登录
• 小团队协作：大家本来就用同一套密码，何必再区分账户
• 自托管服务：在自己服务器上跑的应用，想加个简单防护

它的代价

当然，用共享密码也意味着你要接受一些限制：

• 没有审计日志：不知道是谁做了什么，所有人都一样
• 没有权限分级：要么全能访问，要么全不能
• 改密码麻烦：有人离职就得全员换密码
• 密码容易泄露：通过邮件、Slack 传播，风险更高

所以 Hodor 最适合信任度高的小团队环境。

它是怎么工作的

Hodor 夹在用户和后端应用之间。访问流程很简单：

1. 用户请求到达 Hodor
2. 检查是否有登录 Cookie
3. 没有的话就显示密码登录页
4. 输对密码后设置 Cookie
5. 之后所有请求直接转发给真实应用

没有复杂逻辑，只有最基础的验证和转发。

安全怎么看

很多人觉得“一个密码管所有”很危险，但也要看具体场景。

如果你本来什么都不加就让内部工具裸露在外，那加 Hodor 已经是巨大提升；如果你团队本来就在 Slack 里共享密码，那 Hodor 至少把这件事规范化了；如果你需要每个人的操作记录和细粒度权限，那 Hodor 就不够用了，得用正规的认证方案。

Hodor 只想挡住 casual 的访问和外部扫描，它不是安全团队，而是一扇普通的锁。

部署也很轻

Hodor 作为反向代理，可以直接塞进现有架构：

• 放在内网或私有环境
• 配合 HTTPS 使用（密码传输必须加密）
• 支持 Docker、Kubernetes 或普通虚拟机
• 可以同时保护多个应用

核心思路

Hodor 代表了一种思路：把工具做小，做对。不是每个应用都需要企业级认证，也不是每个团队都需要用户管理系统。有时候，一个专注解决 80% 场景的小工具，反而比什么都想做的重型框架更实用。

想给 Grafana、内部服务或者个人项目快速加一层保护？Hodor 值得一试。