本篇围绕用户登录后被迫修改初始口令的需求展开,先说明 O2OA 平台判断口令过期的机制,即登录时以系统时间与该人员的过期时间点比较。再比较调整过期天数与把过期时间改为过去时点各自能覆盖的场景,前者属全局策略,后者可精确到人。文中给出改配置文件与直接更新人员表的操作路径,并强调批量处理前必须备份、先在测试库确认弹窗行为,验证时避开管理员与刚登录账号。
适用版本 v8 及以上这件事的机制其实很简单,理解了就不会配错。每个人员在组织数据里都带一个密码过期时间点(数据库 ORG_PERSON 表的 xpasswordExpiredTime 字段)。登录时系统拿当前时间和这个时间点比一下:
| 比较结果 | 系统行为 |
|---|---|
| 当前时间 < 过期时间点 | 正常登录,不做干预 |
| 当前时间 > 过期时间点 | 登录后强制跳转修改密码,改完才允许进入系统 |
于是「让用户首次登录必须改密」这个问题,就等价于:让这个人的过期时间点落在他登录之前。两种做法都是围绕这一件事,只是改的位置不同。
进 系统配置 → 安全配置 → 密码配置,找到「密码过期天数」,填一个数字(单位:天)。这对应配置文件里的 passwordPeriod,0 表示永不过期。
| 填写值 | 效果 |
|---|---|
0 | 永不过期,用户永远不会被要求改密码(默认值) |
90 | 超过 90 天没改过密码的用户,登录时被要求改 |
1 | 超过 1 天没改过密码就要改——最接近「首次登录必改」 |
既然判定只看那个时间点,直接把它设成过去,效果就是「立即过期」。有两条路:
在 o2server/config/person.json 里调整 passwordPeriod,含义与界面上的「密码过期天数」完全一致(同一份配置,界面只是它的图形入口)。注意:改配置文件后相关设置以配置文件为准,后续在界面上改会被覆盖,所以两条路选一条走到底,别两边都改。
这条是针对已经建好的用户做批量处理的做法,也是本主题最常见的使用场景:系统上线前把所有人建好,要求大家第一次登录时统一改密码。
先查一下要影响的范围,别上来就 UPDATE:
SELECT id, name, xmobile, xpasswordExpiredTime FROM ORG_PERSON LIMIT 20;
确认字段存在、数据形态正常后,把过期时间统一推到过去(以 MySQL 为例):
-- 让所有人员的密码立即视为已过期 UPDATE ORG_PERSON SET xpasswordExpiredTime = DATE_SUB(NOW(), INTERVAL 1 DAY);
SYSDATE-1)。字段名与表名以实际库为准,不同版本可能有 schema 前缀。| 方法一:密码过期天数 | 方法二:改为过去时间 | |
|---|---|---|
| 作用对象 | 全局策略,所有人员 | 可以精确到人,也可以全量 |
| 能否做到「首次登录必改」 | 不能(当天建号当天登录不会触发) | 能 |
| 适合什么场景 | 密码定期轮换的长期要求 | 上线前集中建号、要求首次登录统一改密 |
| 是否可逆 | 改回数字即可 | 不可逆,需备份 |
| 操作风险 | 低(界面操作) | 中(直接改库) |
实际项目里通常是两个一起用:方法二解决「首次登录必须改掉初始密码」,方法一解决「以后每 90 天必须换一次」。这样初始密码只会存在到第一次登录为止,之后的密码轮换也有制度保障。
别用管理员账号试,也别用刚登录过的账号试——这两类账号的密码过期时间可能已经被刷新过,试出来的结论不准。正确做法:
%o2(v9.5 及之后的默认规则)登录xpasswordExpiredTime 是否真的被更新过(再查一次);② 是否有缓存 —— 退出登录后重新打开浏览器再试,必要时重启服务端。相关内容