Geejing WebBuilder 登录、会话与权限问题，从"进不去"到"管不住"的六个现场

一、先认识登录入口本身

geejing WebBuilder 快速开发平台的登录页面是可配置的——配置项 sys.session.loginPage 指向登录页模块（默认 login）：

截图即默认登录页：用户名称、密码（带可见性切换）、"保存用户名称"开关、登录与重置按钮。这个页面本身就是一个 XWL 模块，所以排查登录问题可以直接读登录页模块的定义（wb/modules/sys/session/login.xwl），验证码开关（sys.session.verifyCode）、按钮事件、提交逻辑全部可见——登录流程没有任何黑盒，这是排查时最大的底气。

症状：登录页打不开 / 打开后样式丢失。先确认 sys.session.loginPage 指向的模块存在；样式丢失通常是 wb 静态资源目录（css/js）没部署完整——用 F12 看哪些资源 404，比猜测快。

二、症状 1：用户名密码正确，却提示登录失败

按可能性排序：

1. 密码方法配置不匹配：sys.session.passwordMethod 决定密码的存储方式（当前环境为 com.wb.tool.Encrypter.getSHA，即 SHA 摘要存储）。如果数据库里的密码是用别的方式（明文或其他摘要）灌进去的，校验必然失败。验证方法：用平台界面正常改一次密码，对比库里存储值与你手工灌入值的格式是否一致；
2. 账号被停用或过期：用户管理的生效/失效日期已过（回忆运维系列第 1 篇的"用日期管生命周期"）；
3. 连接的库不对：系统连接指向了旧库或空库（数据库排查手册里提过的"指向"问题在登录场景的翻版）；
4. 开了验证码但图形加载失败：验证码校验逻辑拿不到会话里的码，永远不等。F12 看验证码图片请求是否 200。

三、症状 2：用一会儿就被踢回登录页

"频繁掉线"的标准排查链：会话超时 → 心跳 → 自动注销，对应三个配置：

• sys.session.timeout = 1800：会话空闲超时，单位秒，当前 30 分钟。用户反馈"看个报表回来就要重新登录"，就是它——把值调大（如 3600）即可，但别调到数小时，空闲会话是安全面；
• sys.session.heartbeatInterval / sys.session.httpHeartbeatInterval = -1：心跳间隔。-1 表示跟随默认行为；需要"只要页面开着就不过期"的场景可配置心跳让会话保活；
• sys.session.autoLogout = false：自动注销开关。开启后到点强制登出，对合规要求高的系统有用，普通系统关闭即可。

判断到底哪个配置在起作用：记录掉线的时间点与上次操作的时间差。固定 30 分钟左右 → timeout；时间不定但页面长时间挂着才掉 → 心跳/自动注销。先测量，再改配置，否则调错了还以为没生效。

四、症状 3：权限改了，用户那边没变化

权限三件套的排查顺序在运维系列讲过（角色启用 → 用户关联 → 模块勾选 → 重新登录），这里补三个更深的坑：

坑一：sys.app.defaultPermission = true 的含义。 该配置表示"默认允许访问未明确禁止的模块"。如果你以为平台是"默认全禁、逐个授权"模型，就会被这个值迷惑。安全敏感系统应改为 false，让"未授权即拒绝"成为默认，然后逐角色授权——这是权限模型的方向性选择，改它之前先评估影响面。

坑二：sys.session.addDefaultRole = true。 新用户创建时自动加入 default 角色。如果你精心设计了角色体系却发现新账号总能看到不该看的菜单，先查这个配置——default 角色的权限会渗透给每个新用户。

坑三：WebSocket 会话独立。 sys.session.wsTimeout（当前 0）与 HTTP 会话超时是两条线，sys.session.anonymousWebsocket = false 表示 WS 不允许匿名。涉及实时功能（在线消息、协同）的权限问题要单独看 WS 会话的这两个配置，别只在 HTTP 会话里打转。

五、症状 4：想强制某个用户下线

管理工具 → 在线用户，选中会话点"注销"（运维系列第 5 篇详述）。这里的补充是注销的边界：注销作用于服务端会话，用户当前页面在下一次请求时被踢回登录页；如果对方页面开着但完全不操作，会话空闲超时同样会收拾它。改密码不会立刻踢掉已登录的会话——需要立刻生效，用注销；改密码是防"下一次登录"。

七、症状 6：同一个账号，两个人同时登录出问题

平台默认对"同一账号多端登录"不做互踢——两个浏览器各自持有独立会话，互不影响。这带来两个推论：正面，用户在办公室和家里可以各自工作；负面，账号一旦泄露，无法通过"对方登录把我挤下线"来发现。

需要"一账号一在线"的强约束时，用在线用户页面配合：登录逻辑里检查该账号已有会话则先注销旧会话（或直接拒绝）。合规系统建议加上这个限制，配合日志里"同一账号短时间从两个 IP 登录"的告警规则，账号共享基本可以杜绝。

八、症状 7：验证码相关的一组怪现象

开启验证码（sys.session.verifyCode）后可能遇到三种怪象：验证码图片裂图——会话没建立（Cookie 被浏览器策略拦了），图片接口拿不到会话里的码，F12 看图片请求的 Cookie 是否带上；永远提示验证码错误——多台服务器部署但会话不共享（负载均衡未配会话粘滞），A 机生成的码到 B 机校验，必错；输对也提示错误——大小写敏感或过期（验证码有存活时间），让用户点图片刷新重试。

集群部署的登录类问题，第一反应就是会话共享：要么配置粘滞会话，要么把会话外置（如 Redis 方案），这是所有"单机正常、集群异常"问题的总根源。

九、症状 8：怀疑账号被盗用 / 被暴力尝试

证据链在日志模块：按用户名称过滤登录记录，重点看 IP 地址（运维系列截图里全是本机地址，生产环境里出现陌生 IP 就是信号）与时间分布（凌晨的登录尝试）。确认后三步处理：注销该会话止血 → 改密码 → 把来源 IP 加入封禁（下一篇安全加固篇详述封禁配置）。

十、一张会话配置速查表

收藏这张表：登录会话类问题的答案，九成在这九行里。