nginx
负责 HTTPS、路径分发、反向代理和阻断未授权访问。
项目目标
把内部小工具的访问控制从人肉记忆、口头授权和数据库手改，推进到可管理、可审计、可交接的系统状态。
第一版不做完整 IAM，也不做通用 API gateway；重点是先把浏览器用户进入内部小工具这件事变成明确的登录、授权和入口审计。
当前状态
已经形成最小可运行闭环：server-side session、用户与服务授权、登录/登出、首次改密、关键安全问题修复、nginx auth_request 接入和入口级审计。
这是内部治理样板，不公开真实域名、服务名称、账号、部署配置或数据库连接信息。
登录server-side session 与密码状态
授权用户、服务和访问关系
审计入口记录与后续业务事件上报
第一版边界
toolgate
负责登录、用户、服务、授权、session、入口审计和 auth-check 判断。
小工具
继续保持独立服务，读取受信任身份头，并负责自己的业务动作。
审计
入口审计先由 toolgate 统一记录；破坏性业务操作由小工具理解语义后上报。
已验证的问题
- 未登录访问内部工具入口必须返回未认证状态。
- 已登录但未授权访问指定服务必须被拒绝。
- 已授权用户可以进入对应服务，并由入口注入受信任身份信息。
- 改密码后旧 session 必须失效，避免旧凭证继续执行高权限动作。
- 一次性设置密码链接使用后不可复用。
为什么不先做通用反向代理
通用代理能集中所有流量，但会立刻引入路径改写、上传下载、streaming、WebSocket、敏感字段脱敏、响应体审计和业务结果解释等复杂度。
更稳的路线是：入口统一、身份统一、审计集中查看，但业务动作仍由最懂语义的小工具负责。只有当这个模型被真实使用证明不够，再讨论是否让 gate 接管更多数据面能力。
不做什么
- 不做 OAuth / OIDC。
- 不做 JWT issuer 或 refresh token。
- 不做多租户、复杂 RBAC 或组织架构。
- 不把小工具代码搬进 toolgate。
- 不把第一版演化成通用 API gateway。
项目价值
toolgate 的价值不是页面，而是把“谁能访问什么、谁改过授权、谁进入过哪个工具”从口头和记忆，变成可查询、可复盘、可交接的系统事实。