把公司登录放在内部工具前面
2026年11月4日，作者：The Casbin Authors
内部工具通常有其中一种毛病。要么根本没有登录，因为它本来就是在笔记本上或者 VPN 后面跑的；要么自带一套账号和密码，没人改、所有人共用。
两种情况都可以在代理这一层解决。如果网关在转发请求之前先要求登录，应用就根本见不到未登录的访客，而登录背后的身份系统就是公司已经在用的那一套。
CasWAF 用 Casdoor 做这件事。这篇讲清楚流程、涉及的三个设置，以及哪些场景不合适。
流程
- 访客请求一个开了登录保护的站点。他身上没有
casdoor_access_tokencookie，CasWAF 把他送去 Casdoor 应用自己的登录页，并记住他原本要访问的路径。 - 他登录之后，Casdoor 把他送回站点域名下的
/caswaf-handler。CasWAF 拿 code 换 access token，写进 cookie，再跳回最初的路径。 - 之后每个请求，CasWAF 先用应用的证书验 token 的签名，再走站点的规则。token 过期或者验不过，就回到登录页。
应用完全不用改。它收到的请求已经通过了检查，cookie 一起带过来。
怎么配
整个配置只有三件事：
-
一个 Casdoor 应用，给这个站点用，放在 CasWAF 自己应用所在的组织里。新建一个或者共用一个都行。
-
一个回调地址，写在这个应用上，用站点的域名：
https://app.example.com/caswaf-handler站点走 HTTP 就换成
http://，CasWAF 会按访客进来的协议告诉 Casdoor。 -
在 CasWAF 的站点里选中这个应用，就是 Casdoor app 那一项。
就这样。谁能进来由 Casdoor 决定：应用属于哪个组织、要不要允许注册、开了哪些登录方式。如果公司已经在用 Casdoor 接 LDAP，或者只放行了 Azure AD、Okta、GitHub 其中之一，这个内部工具会全部继承，包括多因素认证。
应用能看到什么
请求带着 casdoor_access_token cookie 到达。应用如果需要知道用户是谁，可以读这个 token，用 Casdoor 公布的同一张证书验签；不需要的话，忽略它就行。
CasWAF 还会带上 X-Real-Ip，所以应用看到的是访客地址而不是网关地址；以及 X-Forwarded-Proto，让应用知道访客是不是走的 HTTPS。
不合适的场景
- 整个站点都在登录后面。 如果同一个站点还要对外提供 webhook、健康检查或者其他服务调用的接口，那些接口得放到另一个站点或域名上，不开登录保护。
- CasWAF 里没有按用户或用户组的规则。 这个检查只说明访客登录了这个应用，仅此而已。按组或按人限制访问属于 Casdoor 的事。
- 接口调用方要另想办法。 脚本用请求头里的 token 调接口，不是带 cookie 的浏览器；这类端点放在另一个站点上，用别的方式保护。
- 会话在 Casdoor 里。 改权限、停用账号、缩短 token 有效期都在那边做，下一个请求就按新规则走。
为什么放在代理层
另一种做法是给每个应用各自加认证，那意味着每个技术栈装一个库、每个服务存一份会话，每次对“已登录”的定义还不一样。放在代理层只有一个实现、一个出问题时该看的地方和一条审计记录：到达应用的每个请求，前面都对应着 Casdoor 里的一次登录。
具体设置和 cookie 细节在 CasWAF 的登录保护页面。如果还没用上 Casdoor，它的文档里有服务端安装和应用配置的说明。