跳转至

微信客户端与跨平台校园网关：实现及验收记录

日期：2026-11-01。分支：web。接续网络恢复检查点 1a8b1949，不发布安装包。

结果边界

本轮补齐了受限客户端桥、GUI 学校身份续接队列、Windows 系统接入和手机能力说明。清小搭登记了原生登录服务；行在清华登记了临时来访报备服务，并保留路况 8443 的透明转发。这份记录不代表两个微信小程序的所有业务已经完成真机验收。

后续归因更正：用户明确确认小程序可以打开，停在学校网页登录／二次验证页面。前一轮将“请重新登录”直接认定为腾讯微信账号失效，证据不足，撤回该结论。 随后用户已确认清小搭进入业务界面；行在清华临时来访报备也在后续双斜杠修补后，由用户确认进入业务页，详见最后一节。原生 UI 捕捉失败不能作为微信账号失效的证据。

行在清华还包含 THOS、公车、停车、车证等独立 H5。它们继续走已有转发 / 学校认证流程，本轮没有逐项证明共享登录可用，也没有对未知 ITS 服务号全局放行。

已实现

1. 客户端归因

  • Mac 的 lsof 精确 TCP 客户端记录增加 PID/UID 描述接口，原返回 true 的授权接口保持兼容。
  • 保留 -b -w -nP，避免在 WebDAV 等挂载上执行阻塞的文件系统查询。
  • 微信路径限定在本机 /Applications/WeChat.app/Contents/，核对 Apple 签名链、签名团队 5A4RE8SF68 和腾讯微信标识；进程名和 User-Agent 不能替代验证。
  • 实机发现 App Store 版微信使用 Apple 应用签名叶证书，其 subject OU 不等于开发者团队。改为先验证 Apple 链，再读取签名代码的团队和标识。本机微信宿主与 network helper 均验证通过。
  • Windows 增加当前用户 SID、精确 TCP 客户端 PID、当前运行路径和有效腾讯 Authenticode 检查。PowerShell 采用固定程序与编码参数，最多并行 4 个归因查询，另有有界排队；覆盖 16 个并发请求的模拟测试。

2. TLS 分流与学校身份约束

  • 普通浏览器访问身份站时保持透明连接，保留原出口与学校证书。
  • 通过签名验证的微信连接进入受限分流。共享身份只接受已登记小程序与已登记 ITS 服务的只读表单入口，且核对小程序 Referer 或官方业务来源。
  • 清小搭：wxc607b8a0063e7426、www.xiaoda.tsinghua.edu.cn、ITS d982b795884e882abfa8ff3167aeb03e。
  • 行在清华临时来访：wx3cfa534a23db4039、visit.tsinghua.edu.cn、ITS 04655f71b042b9d2d8d10cd566bd9c39。
  • 共享请求忽略客户端身份 Cookie，不把 OneTHU 身份 Cookie 交给客户端。业务票据和 JWT 仍由学校签发，客户端按官方协议兑换。
  • 其他小程序、手动登录与验证请求使用无共享身份仓的原生 Cookie/Set-Cookie 交易；不因未知服务而把整个微信认证链拦成共享网关错误。该路径不读取或写入 OneTHU Cookie 仓。
  • GUI 无法续接时保留官方登录路径；账号切换和退出使旧请求失效。真实二次验证由本人完成。

3. GUI 与后台共享身份

实际检查证明：GUI 清小搭登录成功并完成 Cookie handback 后，两个 ITS 服务仍返回 authenticated=false 的密码表单。单靠“共享 Cookie 已更新”无法承诺小程序免重复登录。因此最终实现转交未兑换的官方服务票据，而不以一次 GUI 登录成功冒充全局 ITS 会话建立。

  • SDK 增加仅存在内存中的受限续接队列。队列传递服务枚举、随机请求 ID 与学校签发的单次服务票据；不传密码、验证码、长期令牌或 Cookie。票据仅存在内存与私有本机 IPC，界面状态和日志只保留服务枚举。
  • GUI 在原窗口使用既有的清小搭 / 来访客户端和既有“记住密码”逻辑续接，将学校真实签发的未兑换短时服务票据转交受限后台请求；无需打开 OH 或用户 CLI 总开关。
  • 队列有账号/epoch 校验、单次领取、超时、冷却和退出撤销；完成回执不能释放其他请求。
  • 网关设置新增“续接微信校园登录”按钮；该按钮只准备学校身份，不登录腾讯微信账号。
  • 学校确认表单移除新设备登记字段，并沿用安装指纹与已有信任因子。清小搭登录日志去掉姓名、证件号与带票据的 URL。

4. Windows 与手机

  • Windows 新增按协议手动代理 / bypass 的 PAC 合成、准备指纹核验、CurrentUser 写入和比较恢复。PAC/WPAD 不作静态合并，保持明确拒绝和原设置保留。
  • 平台能力区分已实现系统接入、进程归因、手动代理共存、原生客户端桥、LAN 和 VPN 前提。构造能力描述不会改变系统设置。
  • Android / iOS 的系统代理或 VPN 原生桥尚未实现，设置中明确说明；没有开放 LAN 监听、广播代理口令或提供伪成功开关。
  • 跨平台接入指南列出手机原生桥的具体实现前提、VPN 共存、目标应用证书策略和真机验收清单。

5. 文案与翻译生成

  • 新增入口含中文、英文，已登记翻译种子和交接批次；本轮新增文案的中英文均已填写。
  • 更新网关共存范围与手机能力说明，并登记 seed。
  • 重新生成翻译交接时发现课程卡片的两个既有未读数量键未登记 seed，生成器会丢失；已补 learn-course-badges-seed.json，保留原翻译，重新生成并校验。
  • 中文与英文均为 7,753 / 7,753；交接 sourceHash be3fd8c88a23dc4acb558acc486d73c0e34027023912c7adc1e35b9861a6e4b5。本次修改包含重新生成的目录与批次。

验证

  • gateway：166 项通过，包括 TLS 分流、同源限制、原生身份仓隔离、伪造签名、错误用户、Windows 并发、原代理合成和恢复。
  • SDK：308 项通过，包括当前设备信任复用、GUI 领取/完成、账号代际撤销、手动准备即时返回、原生独立 Cookie 交易和公共边界。
  • SDK 与桌面 TypeScript 检查通过。
  • 清小搭入口、来访入口、来访客户端专项检查通过。
  • i18n 检查 errors 0，Android 组件 fallback 62 项一致。
  • 实际 Mac 签名验证通过，非仅使用测试夹具。

最新后台部署、学校登录续接与网络复验结果追加在下方。Windows 真机、Android/iOS 原生接入和小程序可见业务验收均与自动化测试分开记录。

恢复与后续验收

保持现有 OneTHU dev 和其他校园网关，观察真实小程序请求是否进入已登记桥及业务是否可用。Referer 的实际形状、微信对用户 CA 的信任以及各 H5 的 CSRF/令牌协议需要据真实流量继续核对；不通过伪造客户端或仅有本地 curl 200 来认定小程序验收成功。

网络恢复按钮位于校园超级代理设置。后台代码采用完整校验、原子替换和代码备份，profile、学校 Cookie、设备信任与 CA 保留。本轮不运行 REA，不解包或修改微信程序。

最终 Mac 部署与实测

  • 完整后台 artifact：0e799d9aac2e02fc9de8b06ccaa941a686a9e4688c51c5489e9fe9e37ee127d5，已校验并安装到原后台路径；原 GUI 未重启，没有新开 App。
  • 替换前恢复原系统代理，替换后先验证私有监听，再自检、恢复系统校园代理。当前 authenticated=true、system enabled=true、recoveryRequired=false，Clash 原手动代理保留。
  • 分别发起清小搭与临时来访的私有出票检查。原 GUI 取得真实官方票据，SDK 校验服务回调及票据见证，两者状态均为 renewed。票据仅用于检查，没有兑换成业务令牌；这一结果证明 GUI → 私有后台的票据链路，不代表微信小程序实际界面已登录。
  • 私有监听与系统监听：Info / Learn 均 HTTP 200，无登录表单或网关错误；Info 校历与待办接口均返回 success。
  • 原 Chrome Info 标签页刷新后无加载滞留、无 GATEWAY 错误；原课程详情仍显示待办作业、课程通知和最新文件。
  • 实际 TLS 检查：普通浏览器身份站连接使用学校证书，Learn 使用网关证书，均正常验证。

  • 证据截图保存在本机 visualizations，未提交含用户浏览器状态的图片或任何凭据。“微信自身需要重新登录”的旧归因已撤回，见下方后续诊断。

  • 最终 WebDAV 复验：原挂载存在且根目录可读；匿名直连及原 Clash 两条新 HTTPS 请求均返回预期 401（未提供 DAV 凭据），TLS 正常；普通外网经原 Clash 返回 200。没有卸载挂载、读取 DAV 文件正文或改动其账号。

后续真实用户反馈与诊断（同日）

  1. 用户确认清小搭 / 行在清华能打开，但仍要求学校登录；当前可见的是学校二次验证网页。因此不能用手动出票检查通过代替小程序共享登录成功。
  2. 补充固定枚举诊断：客户端连接证明、TLS 失败计数、共享 / 独立请求路由、已登记服务 / 回调形状 / Referer 类型，不保存 URL、AppID、查询值、Cookie 或票据。
  3. 诊断后台 405083e9a9497242ab56897104f86bfc30d0abc66c23809d012ed54fca3fb0d4 已加载。替换过程中先恢复原代理，造成其他校园网关短时退出；用户指出该影响。现已恢复系统接入，Info、Learn、校历和待办接口复验通过。后续优先保持运行，不再为读取诊断重启整套后台。
  4. 用户关闭重开清小搭后，本轮网关未观察到任何新的已验证微信连接或 ID / 清小搭请求，票据桥未被调用。进程层面只观察到微信宿主连接原 Clash 端口；不能仅凭这两条连接断言其目标是学校服务。读取本机 Clash 控制接口配置后未找到可用控制入口；没有更改 Clash、节点、规则、TUN、订阅或重启它。
  5. 正在排除微信宿主缓存旧代理或存在独立网络路由。需要先证明校园请求实际进入网关，才能继续根据真实 Referer 调整匹配；不会仅因匹配失败而取消小程序隔离。
  6. Safari 截图的地址实际为 info.tsunghua.edu.cn，正确域名为 info.tsinghua.edu.cn。仓库没有发现该错拼域名。已提供正确 HTTPS 入口；不将此单例外推为 Safari 全部可用。另对当前 Learn / Info 网关叶证书执行 macOS security verify-cert -p ssl -s <host> -L，两者通过，未绕过安全警告。

上述 405083e9 为诊断阶段检查点，后续结果见下节。

真实清小搭闭环与端口连续性

  • 重启微信后捕捉到真实校园请求。清小搭原生请求携带已登记 servicewechat.com 来源，同时使用 Sec-Fetch-Site: cross-site；旧策略把这个合法组合拒绝了。现在仅在已验证腾讯签名进程、已登记小程序和匹配服务三者成立时接受。
  • 新网页导航没有 Referer。增加同一已验证进程、同一账号代际、同一登记服务的 10 秒单次导航授权；必须先有来自登记小程序的业务请求。请求体、凭据 POST、跨进程和重放均不适用。
  • 后台 0838a2f914773d734fa08667b319fb8a91420c74fc1b80dcda7104700dbe235b 加载后，用户确认“已经进入清小搭”。对应真实流量为 25 个共享请求、0 个独立回退、0 个 TLS 失败，清小搭官方票据续接完成。此项才作为小程序业务登录的可见验收。
  • 微信会缓存 PAC 指向的端口。新增私有 gateway/endpoint-hints.json，记录监听端口和 PAC 随机路径；后台重启沿用地址。文件使用原子写入、0600、所有者/符号链接/硬链接检查，不含账号、Cookie 或令牌。端口被占用时安全失败，不终止其他进程。
  • 部署前完整校验和暂存代码，单个受保护流程完成短时替换与自动恢复；保留原 GUI、CA、四个网络服务的 PAC URL 和代理端口。0838 部署耗时 7.6 秒，后续部署耗时 6.3 秒；存在短暂后台中断，不宣称零停机。没有改动 Clash、节点、订阅、规则或 TUN。

行在清华临时来访的后续检查点

  • 用户反馈来访入口仍要求学校登录／二次验证。真实轨迹显示 Visit 同源业务请求已进入共享通路，随后 ITS 导航没有匹配旧版严格表单规则，回落为独立交易；未触发 Visit 票据队列。
  • 当前增加已登记 ITS 表单的大小写十六进制服务号、可选结尾斜杠、模式 0 / 1 / 省略模式的解析。模式从请求逐层传到 GUI 与学校客户端，省略时仍省略；未知服务或其他模式保留独立官方流程。没有把模式 1 改成模式 0。
  • 新诊断只增加模式与服务号大小写分类，不记录实际 URL、查询值或账号。具体真实 URL 变体尚待本次重新打开入口确认，不能仅凭测试推断根因已闭环。
  • 当前已加载后台 92dcb90bdb67223aa2c00c1fd507755fb8b95c6eb98b9933e566aa576e0a60ea；Info / Learn 均 HTTP 200，无登录表单或网关错误；Info 校历和待办均 success。PAC URL、端口和 GUI 均保持。等待用户重开来访入口的实际结果。
  • 来访表单与报备均未填写或提交；整个过程没有运行 REA、解包微信、自动发送验证码或登记信任设备。

官方来访入口的双斜杠（后续真实复现）

用户再次反馈仍在登录页，并提供截图：实际是账号密码首屏，还未进入二次验证。最新独立认证记录证明已验证微信进程请求进入了 ITS，但路径归类为 other-login，回退独立登录；手动私有出票检查则由现有 App 在约 3 秒内完成。这一检查仅证明 App 有能力出票。

通过普通 Chrome 页面操作复现官方来访网页，选择“师生”并点击“统一身份认证”，浏览器实际历史为：

  1. visit.tsinghua.edu.cn/visitor/mobile/sso
  2. id.tsinghua.edu.cn/do/off/ui/auth/login/form//<已登记来访服务号>/0?/visitor/mobile/sso
  3. 浏览器自身确认流程继续到 checkSingle。

核对服务号为已登记来访服务、模式为 0、回调为既有来访路径。关键差别是 form 后有两个斜杠。此前大小写、尾斜杠与模式变体修补没有覆盖这一位置。这里使用正常页面导航与限定时间的浏览器历史，不分析第三方编译脚本、不运行 REA，不填写验证码或发送验证通知。用于观察的临时标签页已关闭。

Gateway 与 SDK 现在同时接受该位置一个或两个斜杠，仍要求已登记服务、原模式和正确来源；三个斜杠、其他服务、其他认证模式或恶意来源继续拒绝共享。来访官方回调的 Referer 检查也覆盖同一双斜杠格式。诊断单独保留最后 8 条认证请求，后续脚本与图片不会将其覆盖；不保留原 URL、任意服务号或查询值。

新增回归覆盖真实格式、票据只用于对应服务、拒绝其他服务/模式与重放、认证记录在资源请求后仍可读。当前 gateway 166、SDK 308 项通过，SDK 类型检查通过。

已在原 dev 后台加载完整 artifact f356231f969e8af3d03eef569f9651c110856da3aa9d9491cdb4a1e0882a10c3。本次保护替换 9.6 秒，四个 PAC URL、监听端口、原 GUI 与 CA 保留；Info/Learn HTTP 200，校历/待办 success，系统接入 enabled、recoveryRequired=false。已请求用户返回行在清华并重新进入来访入口，结果如下。

来访报备最终可见验收

用户返回行在清华重新打开后明确回复：“已进入来访业务页”。与此对应，真实已验证微信连接的认证记录已从 identity-other / independent 变为 identity-form / visit / mode 0 / shared，原回调保持 visit。队列从 queued 进入 renewed，随后出现官方来访回调和业务请求；TLS 失败为 0。这一闭环证明本次认证入口匹配修补在真实微信页面中生效。

完成后再次复验：Info / Learn 均 HTTP 200，未出现身份表单或网关错误；Info 校历 / 待办 success。WebDAV 原挂载保留，匿名直连返回预期 401；原代理路径首次 8 秒检查超时，12 秒重试返回预期 401，原代理普通外网返回 200；未提供或更改 DAV 凭据。没有填写或提交来访报备，没有发送验证码、登记设备、变更 Clash 或重启原 OneTHU App。

当前 Mac 的清小搭与行在清华“临时来访人员报备”均有用户确认的业务页结果。此结论只覆盖这两个已登记服务；Windows 真机、手机原生桥及行在清华其他独立 H5 的边界仍按本文前文与跨平台指南记录。