APM 门户访问：应用会话究竟归谁？

通过 BIG-IP APM Portal Access 发布内网应用，是一个关于会话的决定，而不是复制一台虚拟服务器。门户放用户进来，重写配置文件把选定的请求留在网关路径上，而应用仍然拥有自己的会话。五项检查把行为可预测的设计与那种让服务台逐个用户地了解超时的设计区分开来。按顺序做完，并在第一个不成立的检查处停下。

检查 1：资源是被发布，而不只是被链接

webtop 中的书签只能证明用户能看到一个条目，不能证明应用已被发布。去找访问配置文件、重写配置文件和把两者组合起来的虚拟服务器，然后确认资源指派指向的正是你以为的那个应用。这三者中任何一个缺失或不一致，后面的清单就没有意义。

半发布的情形在入口处看起来是健康的。虚拟服务器带着访问配置文件，而重写配置文件却被限定在另一个资源 URI 上，于是 webtop 条目出现、首页加载成功，随后子路径请求离开网关路径，直接到达后端。镜像的情形则是资源被指派给了错误的应用：书签能打开，打开的东西却没人批准过。

检查 2：后端会话是另一种独立状态

即使 APM 认为用户已经登录，后端仍可能要求自己的认证。受支持的 SSO 集成会为你建立这种关系，但接受门户登录并不意味着每个应用都接受同一套凭据或同一个会话 Cookie。如果该资源没有配置 SSO，应用会在已经通过认证的门户内部要求自己的登录。

为了改变可见的提示而关掉 SSO，是常见而糟糕的捷径：它改动了认证设计，却没有触及产生该提示的生命周期。反过来，应当先决定后端登录到底该不该出现；如果该出现，就把它作为已发布流程的明确一环。

检查 3：有两个时钟，而且不是同一个时钟

APM 的访问配置文件带有非活动超时和最大会话寿命。应用带有自己的空闲计时器和 Cookie 过期时间。延长门户的计时器不会延长应用的会话，缩短应用的会话也不会把用户从门户登出。

经典的支持电话来自一对不匹配的时钟：门户仍然有效，应用会话已经失效，用户看到的登录表单似乎与门户相矛盾。这是正确行为，不是故障；解决办法是为这个应用选定哪个时钟应当先到期。

检查 4：注销有明确的范围

写下应用的退出按钮应当结束什么：只结束该应用、整个 APM 会话，还是更广的身份提供者会话。访问配置文件支持带可选延迟的注销 URI 列表，当需求正是如此时，你就这样让应用的注销去结束门户会话。没有它，应用的注销会让门户继续存活，随后的一次请求可能悄悄把用户重新登录。

还要考虑对同一门户中其他资源的影响。如果从某个应用注销会结束另外六个应用的会话，除非事先与应用所有者商定，用户会把它叫作缺陷。关掉标签页再回到 webtop，并不能证明什么已经结束。

检查 5：应用能挺过重写

Portal Access 会重写选定的 Web 内容，而重写是有边界的。现代客户端特性、后台工作线程、上传流程和联合登录，都可能落在某个版本能处理的范围之外。F5 的按版本划分的兼容性矩阵是承诺之前必须阅读的文档，因为限制与版本相关。

要测试的是关键流程，而不是着陆页：登录、走完每一项必需功能、应用需要上传就上传、让预定的会话到期，并走遍每条注销路径。页面能渲染一次，并不证明应用可用。

当必需流程无法被重写时，改用有文档的联合、反向代理或网络接入方案。被要求像通用隧道那样工作的浏览器门户，能通过演示，却过不了审计。