摘要

  • LACNIC 公开 PAI 客户端的权限缓存期限是两分钟。在符合外层异常处理条件的刷新失败后，旧条目可以重新计时，原来的权限对象则保持不变。
  • 随附测试用格式错误的 JSON，明确期待返回旧的已认证对象。正常解码的新拒绝回复会建立新条目，不属于这个回退场景。
  • 源码没有证明该路径正在生产中使用，也没有证明已撤销的权限继续有效。它能证明的是：刚续时的缓存，不一定包含刚确认的权限。

刚更新的东西，未必刚得到确认

如果一个权限结果刚从服务端取得，使用者可以问它是什么时候取得的。如果一个缓存刚被应用程序重新计时，使用者只能知道这个容器什么时候被触碰。这两件事常常发生在一起，于是很容易被当作同一件事。真正考验边界的是：新回复没有读懂，容器却重新变年轻了。

这里没有发生新的授权决定，应用程序仍然依靠先前的答案运行。它可能是在合理地渡过短暂故障，也可能已经超过业务能够接受的旧答案年龄。两种情况不能只凭“缓存尚未过期”来区分。过期规则必须说明，起点究竟是最近一次可靠回答，还是最近一次对旧容器的续时。

这种区别出现在 LACNIC 公开的 pai-auth-ws-client 中。本次检查固定在提交 b85523718bfdbd834c85add8e06c3b4a1b813e59，该提交位于 2026 年 9 月 14 日观察到的仓库主分支。固定提交让读者可以复核同一份实现，并不代表它就是某个生产系统正在运行的版本。

项目 README将其描述为服务于 PAI 认证、授权和会话相关功能的 Java 客户端。说明文件能确定项目用途，却没有给出客户端安装普查。不能从公开项目跳到“全部 LACNIC 应用都使用这条路径”，更不能从源码中存在一个分支，跳到现实中已经发生了越权。

两分钟是缓存期限，不是权限寿命

PortalWSClient使用一个静态、进程内的 ConcurrentHashMap 保存权限结果。键是传入方法的原始 token，条目内是 TokenData 对象和一个可以修改的时间戳。CACHE_DURATION_MS 设定两分钟期限；是否过期，根据当前时间与该时间戳的差值判断。

如果条目没有过期，方法直接返回已经存下来的数据，这条路径不会再去获取 /authorization 的新回复。这是缓存的通常用途：减少远端调用，避免每个业务请求都承担一遍依赖服务的等待和短暂故障。仅凭这种正常行为，不能断言授权系统设计不当。问题在于，哪些行为有权重设这个“尚未过期”的起点。

条目过期后，方法会把它从共享映射中删除，再尝试取得并解码新结果。不过，当前方法的局部变量仍保留着那个旧条目的引用。从映射中移走，不等于这次执行已经失去旧对象。这个细节让后续异常处理仍有东西可用；它是连续运行机制的实际支点。

如果新回复成功解码，方法就把新数据装入新的缓存条目并返回。成功解码不等于一定允许访问：能够正常读懂的负面权限数据也沿着新条目的路径处理。因此，“客户端收到最新拒绝后依然坚持使用旧授权”并不是这份证据支持的结论。读懂拒绝与读不懂回复，必须分别讨论。

外层 IOException 处理才是这里关注的分支。如果仍有旧条目的引用，方法调用 cached.extend()，把那个条目的时间戳改成当前时间，重新放回映射，并返回先前保存的对象。这一步没有取得新的、成功解码的授权决定，改变的是装着旧决定的容器的计时起点。

于是，缓存再次获得两分钟窗口，而原始权限回复没有获得一次新的确认。下次过期后的刷新如果再次遇到符合条件的失败，同一分支还可以再次续时。在这一个类中，没有单独保留原始成功回复时间的不可变字段，没有从那次回复起算的绝对年龄上限，也没有限制续时次数的计数器。

这些缺项是对这份类定义的描述，不是对整个应用架构的判决。调用者可以在别处记录年龄、限定宽限期，或者在敏感操作前要求另一项权威核验。源码既不能证明这些外围保护存在，也不能证明它们不存在。它只能告诉我们，这个缓存自身的两分钟，并不自动回答旧权限数据最多可以有多老。

测试主动保住了旧对象

随附的PortalWSClientTest让实现意图更明确。名为 testGetTokenDataReturnsCachedDataWhenRefreshFails 的测试，先用模拟 HTTP 回复产生正面的认证样例，再把缓存时间戳人为设到五分钟前，随后给第二次模拟调用一个格式错误的 JSON 回复。

测试断言期待同一个已认证对象被返回，并期待两次模拟 HTTP 执行。它不是在报告“生产中的用户五分钟后仍可访问”。五分钟是测试主动写入的旧时间，HTTP 回复也是模拟的。本次文章检查阅读了测试源码，没有运行测试，没有访问生产授权端点，也没有使用真实凭据。

即使限定如此，测试仍然提供了重要的正面信息：旧对象在这种刷新失败后存活，是明确受到测试保护的连续运行行为，而不只是读者从一段异常处理里猜出的偶然结果。要评估它，先承认它在解决一个真实问题，比直接给它贴上越权标签更有价值。

权限服务短暂不可读，不代表所有仍然合法的会话都应该立即终止。一刀切断访问，可能把一个小范围的依赖故障扩大成业务停顿。允许有限的宽限运行，可以降低这种放大效应。合理的批评应落在“有限”究竟如何计算、谁可以判断、哪些操作可以继续，而不是落在“任何旧答案都不能再用”。

同一份代码还会就暂时使用延长后的缓存写出警告。不能忽略这项反证，把行为描绘成完全隐形、没有任何观察入口。运营团队可能监测到警告。更窄的问题是：警告没有把原始成功回复的年龄放进返回给调用者的权限对象中，也不能仅凭出现一条警告推算出旧数据已经持续多久。

返回权限的人，没有同时交出时间

TokenData包含认证状态、token、角色、错误字段以及 ipAllowed。这个数据对象没有公开“最后一次成功回复时间”，没有新鲜、宽限或不可用的状态分类，也没有说明当前值来自旧缓存回退。只看这些字段，调用者无法知道这个对象刚从远端取得，还是刚被重新装回一个年轻的缓存。

这并不意味着 token 本身永不过期。token 的密码学有效期、缓存当前窗口和发行方当前角色状态，是三项不同命题。一个有效期尚未结束的 token，并不自动证明角色分配从未变化；一个尚未过期的缓存，也不自动证明刚发生过新的远端核验。把三者揉成“有效权限”，会省掉真正需要证明的连接。

外围应用可能检验 token 的到期时间、执行来源 IP 限制、保存自己的成功回复时间，或者在关键写操作前再次确认权限。那些做法都可能改变现实后果。这里不能把它们从架构中删掉来制造风险，也不能把它们凭空补上来消除疑问。正确的边界，是把客户端已明确返回的东西与应用尚待核验的东西分开。

还要问“成功回复”究竟指什么。公开的PortalHttpClient用 TrustAllStrategy 和 NoopHostnameVerifier 构造 HTTP 客户端。在这个辅助组件中，URL 写着 HTTPS、JSON 又能解码，并不足以单独证明它已经密码学核验了回复发行方的身份。

这是另一项限定在源码中的观察，不是生产 TLS 审计，也不是拦截、攻击或泄露证据。它与时间问题的连接很具体：如果设计要保存“最近可靠回答的时间”，还应定义何种经过来源认证的回答才有权重置那个时间。给能够解码的字节加上精确日期，不会自动补上来源可信度。

格式错误不是所有故障的共同名称

测试演示的是一种格式错误回复路径，不是一份全面的网络故障保证。readUrlToken 会较宽泛地捕获异常，并可能返回空值；外层可续时的处理则捕获 IOException。空回复、连接错误与格式错误的 JSON，不应该在没有执行和核验相应路径时被写成完全相同的行为。

所以，“只要授权服务故障，客户端就一定继续工作”过度扩大了连续运行保证；“任何故障都会保住已经撤销的访问”过度扩大了风险。两句话都把有限的源码证据换成了关于具体 token、应用控制和生产环境的全面断言。它们听起来有力，却抹去了读者判断影响所需的变量。

能够站住的结论是：随附测试中的格式错误回复场景，期待旧对象返回；相应回退会重新设置缓存条目时间。这个类没有为重复的合格回退单独保留一个从原始成功回复起算的绝对上限。是否影响实际权限操作，仍取决于安装版本、发行方语义和调用者的额外验证。

同样不能把仓库新提交日期当作风险开始日期。一个公开版本何时发布、何时被某个应用采用、某个账户何时改变权限，是不同事件。本次只固定了供复核的代码版本，并未建立部署时间线。避免这类日期混用，和避免两只缓存时钟混用，遵循的是同一个证据原则。

要验证绝对宽限，就应把待证命题写成可观察的问题，而不是只问旧对象有没有返回。一次回退后，原始成功回复时间是否仍保持不变？再次回退后，是否仍从同一个起点计算上限？到了上限，调用者能否区分正常拒绝、依赖不可用和本地不再接受旧数据？这些是建议的验证问题，并非本次已经执行的测试结果。

还需要一项对照：如果更新得到格式正确的负面数据，系统应该沿着新回复路径工作，而不是继续沿用故障宽限的叙述。已有源码明确提供了新条目路径，因此对照不应被省掉。把拒绝当故障会模糊发行方已经给出的答案，把不可读当拒绝则可能扩大停顿；状态设计的价值就在于不让两者互相冒名。

这个验证方法也说明了为什么“返回同一个对象”只是有限证据。同一对象可以服务于合理的短期连续运行，也可以被外围应用附加独立的限制。需要观察的是决定如何形成：调用者拿到对象后是否识别年龄、是否验证 token、是否按操作要求另一项确认。单独看对象相同，不能倒推出最终业务操作已经获准，更不能倒推出某项未经授权的操作已经发生。

宽限可以存在，但应有起点和终点

一种更清晰的接口会保存两份时间：最后一次经过来源认证、成功解码的授权回复时间，以及缓存最后一次触碰时间。续用旧条目只能改变后者，不能悄悄改写前者。调用者收到的结果也可以明确区分新鲜数据、宽限数据和不可用状态，不必从一个正面的认证布尔值猜测连续运行的性质。

宽限上限可以从可靠回复那一刻绝对起算。这样，每次失败后再碰一下缓存，就不能把宽限期不断向前推。上限也可以按操作区分：一项可以撤回的读取，与修改管理员、授权他人或发出不可逆指令，未必应接受相同程度的旧答案。这些是分析用的决策类别，不是已经确认使用这条路径的 LACNIC 功能清单。

日志可以把回退次数、回复年龄和声明的降级模式联系起来，却不必记录原始 token 或完整会话。重新取得可靠回复后，宽限状态应结束；读懂的新拒绝仍应保持拒绝。监控的目的是解释旧答案为何仍被接受，而不是为了审计把凭据复制到更多位置。

这些建议不是 LACNIC 已经公开承诺的修复，也不是关于其全部外围控制的结论。它们只是把一个可复核的实现细节转成更明确的接口要求：两分钟的缓存期限可以是正常工程选择，但它不能在没有另一只时钟的情况下，被当成权限决定的最大年龄。

为宽限设置终点，并不意味着所有依赖抖动都必须向用户显示错误。应用仍可以在明确的容忍范围内避免不必要的重复请求。变化只是把连续运行从隐含结果变成可解释的政策：不是声称发行方刚刚重申了权利，而是承认自己暂时接受先前的答案。这样，业务负责人才能评价可用性收益与不同操作的后果，而不是只能看到一个仍为正面的认证字段。

同样，说明不可用并不等于撤销权限。不可用是关于当前核验能力的状态，拒绝是关于发行方决定的状态，宽限是关于应用暂时承担什么风险的状态。清楚表达三者，才能在恢复可靠回复后回到正常边界，也让后续审查能够判断当时是谁依据哪项规则继续工作。缓存可以保存数据，但不应顺便替这些不同判断选定一个共同含义。

这也是运营交接时应留下的解释。下一班团队不应仅从一个年轻的时间戳推定依赖服务已经恢复；它需要知道最后可靠回复的年龄和当前允许的降级动作。如此，服务恢复、主动限流与权限变更才有各自清楚的记录，而不是都被折叠进“缓存正常”四个字。

资料来源

以上五个链接分别指向同一提交中的 README、PortalWSClient、PortalWSClientTest、TokenData 和 PortalHttpClient。它们支持公开源码与模拟测试场景的分析，不证明生产采用、测试执行、真实 token 的有效性、撤权绕过、凭据失陷或未经授权的操作。