VPN 密码修改页面：与身份存储保持一致

打开密码修改页面，像用户那样阅读它，然后问：凭证究竟归哪个服务所有。页面只是表单，身份存储才是权威。若两者不一致，用户会遭遇密码被拒、重置后毫无变化，或成功提示却什么也没改。把流程从界面一路走到后端，是发现问题的唯一办法。

先对操作分类：普通修改、密码过期流程，或忘记密码后的找回。

三种操作，三套流程

普通修改假定用户知道当前密码并能证明这一点。密码过期流程可能只允许一个受限会话，其中仅开放修改。忘记密码后的找回需要完全不同的身份证明，而且可能交给身份提供方处理，而不是在 VPN 网关完成。三者各有自己的端点、后端支持和会话规则，一个表单无法同时正确服务三者。

在联合部署中，网关可能根本不收集新密码。检查流程是否重定向到身份提供方，以及页面文字是否仍在描述本地表单。

策略究竟从哪来

向身份所有者询问允许的长度、字符集和任何适用限制，然后编写与之相符的说明。在帮助文本里杜撰组合规则，或承诺后端会拒绝的通过条件，都会制造支持工单。NIST 的数字身份指南倾向于清晰指引和有用反馈，而非任意规则；但组织的实际策略仍然说了算。一份出版物并不能证明某个目录已经如此行事。

让错误信息有用，同时不泄露机密。回显部分已输入密码的信息，或工单中带有此类信息的截图，会把支持材料变成凭证泄露。

与后端相符的措辞

页面应当点明具体流程，而不是抽象描述策略。说明修改在哪里发生、需要什么证明，以及其他会话会怎样。如果修改会让用户在所有设备退出登录，就写明；如果其他设备仍保持活动，也要写明。用户困惑地重试一次已成功的修改，是本可避免的支持成本，更好的措辞能防住它。

本地化可以改变说明的语气，却改变不了后端接受什么。

测试流程，而非页面

使用获准的测试账户，走一遍文档记录的修改、拒绝情形、密码过期情形以及随后的登录。若 MFA 或联合重定向属于已批准的流程，也要走一遍。页面渲染正确只验证了呈现，别的什么也没验证，因为凭证操作是否完成由身份服务决定。

记录每个用例的结果，以及所用账户和时间。对管理员有效、对普通用户失败是常见结果，而记录才能让它显现。

然后更新页面，如实描述实际发生的情况。这就是全部工作。